Josh

I'm thinking a 2D drawing tool would be nice, with the ability to form concave shapes and have them triangulated correctly.

No, it's a significant reworking of the way collision shapes are handled. If introduced into LE2 it would definitely create new bugs, so I'd rather just focus on the new engine. It's also using a newer version of Newton, so it would probably require a reworking of all .phy files, and that went very badly last time I did it. The joint strength issue is sort of a non-issue, in my opinion, because the person who posted it was using joints between bodies with big big differences in mass. That's going to cause problems no matter what. I have found the existing joints to be very stable, and if anyone can show me otherwise I will look at it. If joint stability is a concern, then I don't see PhysX offering any advantage there...from what I have seen it would probably be much less stable. As far as visualizing joints, that's not something I need the physics lib to support, I just add it myself. PhysX might have some built-in helper function for that, but honestly we're talking like one hour's work to set it up for all joints. The people who are most likely to make use of it are the flight sim people. I have gotten a ton of serious requests from flight sim companies...for some reason they are attracted to LE, but they want even bigger worlds. That's something we can do uniquely well in the future, and no one else is going to pursue it because they are designing engines to run with 256 mb shared memory. Also, if we can offer big worlds, it does mean a lot of sales. It's not my business to tell people what they can and can't do. I like the idea of driving on a limitless road and stopping to kill mutants.

Speaking of, I just updated Newton from the repository and it looks like version 300 has soft bodies, or at least an early implementation. I'm pretty satisfied then. There are some weird things about physics in LE2, but I think careful planning can avoid those issues we experienced before.

Maybe you have only a back-facing polygon, so there is nothing to cast a shadow and block the light?

Shadows?

Brush geometry uses lightmaps, not vertex lights. I opened one of your maps and it had no lighting information, so press the lighting button and do that first, then export.

I don't understand this question.

Does anyone know how to register a new MIME type and create an ActiveX control that calls a local DLL on the user's machine? I am not trying to download and call a DLL, just call an existing one. It should work on IE, FF, and Chrome.

I recommend using it, but if you don't want to, you can look at the source.

Discuss here: http://www.leadwerks.com/werkspace/topic/3135-physics-library/page__view__findpost__p__36554

I am using Newton because: -PhysX guarantees all the cool open-world stuff I want to do down the road is impossible. There's just no way we can do it. I talked to the guy in charge of PhysX at NVidia. It can only handle 40-50,000 bodies, not millions like we are used to. -I have been able to get scaling working with Newton, it just took a lot of careful design that's hidden from the end user. -I have the source to Newton, and the only area I find it lacking in is soft bodies. It's possible I can some day add my own soft body implementation in Newton. It's impossible for me to ever add 64-bit float support or vegetation into PhysX, because it's closed source. PhysX development revolves around consoles, so the memory constraints of those guarantee large worlds are not a priority. This is pretty much what NVidia told me, in different words.

I think I know what is happening. Previously, the base texture was ignored and now that I fixed that, it appears black if there is no base texture. I should add a white texture that gets used in its absence.

Model is an abstract class. In Leadwerks3D, you are always creating an OpenGL3Model, OpenGLES2Model, etc. Constructors can't return a derived class from an abstract one. What Model::Create() really does is call this: GraphicsDriver* driver = GraphicsDriver::GetCurrent(); if (driver) return driver->CreateModel(); And in OpenGL4GraphicsDriver: Model* OpenGL4GraphicsDriver::CreateModel() { return new OpenGL4Model; }

When the argument was about supporting C# the way MS says to, I don't really care about that, because anyone who has an opinion other than mine, or an opinion on a subject I have no opinion on, is by default wrong. However, when the argument becomes about giving a consistent API for all languages, then it changes. Here I'm promising this guy the API is going to be 100% uniform across three languages: http://www.leadwerks.com/werkspace/topic/4148-leadwerks-keywords-and-commands-the-same-as-others/page__view__findpost__p__36512 Static methods are a way to achieve that. Plus, C++ programmers have always complained about global functions like LoadModel(), even though I thought constructors were inappropriate for this. I'm surprised no one suggested static methods back when we first had that discussion, but maybe they did and I just missed it. Lua already does something like this with its libraries, like time.GetTime() or whatever it's called, so we have two languages that definitely tend to use this approach, and one that's sort of undefined (C++).

The command reference is here: http://www.leadwerks.com/werkspace/page/Documentation/le2/_/command-reference I can't comment on Unity's command set, because I am not familiar with it. In Leadwerks Engine, we have some inconsistency between languages. In the upcoming Leadwerks3D, we have complete consistency between C++, C#, and Lua. For example: C++ Model* model = Model::CreateBox(); model->SetPosition(1,2,3); C#: Entity model = Model.CreateBox(); model.SetPosition(1,2,3); Lua: local model = Model:CreateBox() model:SetPosition(1,2,3)

From my time at Heavenly, we call it hoar frost.

1. Yes. 2. You can change the directory the editor loads files from in the options. A Lua app automatically loads assets from its own directory, recursively, but you can call RegisterAbstractPath() to load a directory from somewhere else.

It would be easiest to keep each animation in a separate file and use LoadAnimation() to attach them to a model.

What does the Bind() function do and how is it defined?

Just call LoadMesh() as many times as you like, and the engine will automatically instance them.

I see. What is I added an "extra" parameter to be passed back to the callback, like this?: class Thing { Model* model; virtual void OnCollision(Entity* entity, Vec3 position, Vec3 normal, float speed); }; //Extra paramter gets passed back to callback: void CollisionCallback(Entity* entity, Vec3 position, Vec3 normal, float speed, char* extra) { Thing* thing = (Thing*)extra; //Call the class function: thing->OnCollsiion(entity,position,normal,speed) } Thing* thing = new Thing; thing->model = Model::CreateBox(); thing->model->SetCallback(CALLBACK_COLLISION,CollisionCallback,thing); This would do the same thing you are describing, just one global callback function has to be declared, and it will work with all languages.

I've seen it done both ways. Valve games usually use a fixed size in a window, others vary.

You actually can if you use pointers, which I always do for complex objects like entities. You can store Models or whatever in a list of type Entity*, and cast them back to Model* later. The problem is the user can't be responsible for the creation of every single entity. When you load a model, it has children from the file that are automatically created. When you load a map, entities will be automatically created.

No, you probably would not want to do that. The only time it could improve image quality is if things were rotated.

My goal is not to support C++, C#, or Lua the "right" way for each language. My goal is to support one uniform design that is a compromise of all three, and bend each to follow it. We may have an elegant solution to this that works uniformly with all supported languages: Static functions: http://www.leadwerks.com/newwiki/index.php?title=Static_Functions