Niosop

I think the biggest threat might be Unity moving to a deferred lighting system (ether entirely or as a swappable rendering subsystem). They have a bigger development team, more money, more users, can deploy cross platform and to browsers, a great editor, plus people can write stuff in the free version and upgrade when they want the Pro features. LE's big advantage is visual quality, so if that gap is closed, LE doesn't really have any advantage anymore. I think the one big thing that Josh can do is make things more accessible to us, enable us to disable subsystems (Audio, Physics, etc) so we can replace them if desired, expose as much of the engine as possible at as low a level as possible so that we can contribute to the development, fix bugs, add features. Make the editor support plugins and expose all editor events to these plugins so we can contribute plugins back to the community. I'm really impressed with what Josh has done, but he can't do it all alone, as shown by the number of bugs in the tracker that are unresolved and the shear number of feature requests. All that being said, I really do like LE, enjoy developing in it, and look forward to what Josh is going to do with it next. The price is great and well worth picking up a license even if you're not sure that you'll end up using it for your project. The community is knowledgeable, helpful and generous with code and assets.

Yes, it's a symptom of the updated shadow caching system. It's not realizing it's cache should be invalidated for some reason, but don't have source so can't do anything about it I think it will probably be a quick fix for Josh though.

Does it for me on Dynamic and Dynamic+Static+Buffered and Static (if I move a static object). Dynamic+Static works intermittently for me, an objects shadow will follow it properly for a little bit, then get stuck in the same place for a few seconds, then jump back to the object.

Looks kind of cool, but the effect seems a little odd. Like a bubble of darkness behind objects as you look at them. But the darkness always stays on the other side of an object no matter what direction you look at it from, regardless of what's around it. If you had a flashlight it might look correct, but w/ lighting that isn't moving you don't expect the lighting to change just because you move. But it does look pretty cool.

Can anyone else confirm this? In the editor (haven't tried as a standalone program but I'm assuming it's the same) shadows cast by a spotlight never update. So it "bakes" the shadow onto the terrain/other objects. This is only for spotlights, point lights work fine.

I have some animated models moving around. The SSDO induced darkening doesn't update when they move, effectively baking the SSDO effect onto other objects/terrain. Hmm, might be something else, just returned to the original shader and it's still doing it.

Forget Torque3D. They have some cool demos, but from everything I've seen and heard, the codebase is a mess. Unity is a great engine, but it is built to run on a wide variety of hardware. You can write shader code that is conditional on it being supported by the card w/ fallbacks to other techniques if the preferred one isn't supported, but it would involve knowledge of writing shaders and what different generations of cards support. It's editor is a little more friendly than LE's is, and it does a little better job of exposing engine functions to the user than LE does at this time. You'll also have to pay 7.5 times as much as LE to get the Pro version to get real time shadows, which you can't really live without for the type of game you are talking about. Unity's performance profiler and asset streaming system are some advantages it has. LeadWerk's rendering engine looks awesome and it's editor is pretty good. There are some rough edges, but Josh makes frequent updates to try and address these, although keep in mind that your priorities are not always going to be his priorities as far as feature additions/bug fixes. You can expect new features/fixes to come out for LE every few weeks, whereas Unity seems to release bigger updates every 6 months to a year. I'm currently doing parallel development in both LE and Unity. I'm more productive in Unity usually because of it's asset pipeline and how polished the system is, but the same scenes using the same assets tend to look a little better in LE. So between LE and Unity, they're both great but different. For your project, LE is probably a better fit as it has a more advanced lighting system and offloads a lot of stuff to the GPU. And Unity costs 7.5 times more and definitely isn't 7.5 times better, so LE wins hands down as far as bang for your buck goes. I'd say try the demo of LE and download the Unity free version and play with both so you can get your feet wet without shelling out any cash. That should give you a better feel for what works best for you.

Seems like it adds a shine or glow around the edges of objects. I hadn't tried tweaking the values yet.

If you have an .obj version of it I'll be glad to take a look at it and see if I can fix it.

Check the faces that are appearing black. If your modeling program supports it, have it display the normals or turn off two sided rendering. Then you can see if those faces are facing the wrong way and flip the normals on those if needed. Actually looking closer at that picture, it seems that it's definitely just that those faces just need to be flipped.

You want either itoa or sprintf to convert the integer 5 to the string "5". As it is you're telling it to try and make a string out of whatever is at a memory location, which will cause a crash. Probably something like this: int i = 5; char a[30]; strcpy(a, "SCORE "); char buffer[30]; itoa (i,buffer,10); strcat(a, buffer);

Try it with just a diffuse map, no normal map. If the problem goes away then it might be that the Y component of the normal map is inverted. If the problem doesn't happen when only using a diffuse then you can try adding: normal.y *= -1.0; right after: normal = bumpcolor.xyz * 2.0 - 1.0; in mesh.frag and see if that fixes it. If so, then you can leave it like that if all your normal maps are generated the same way, or use -Y in your normal mapping program and leave the shader the way it is.

Real estates should be real estate in English.

Pretty easy for us to implement ourselves by creating our own scene loader. You'd probably be best served by loading the terrain/vegetation using the standard LoadScene command, then using your own loader to load the individual items one at a time so you could track status. At least it's a temporary solution until Josh adds this in, if he does.

If you download the LETheora library I made (http://leadwerks.com/werkspace/index.php?app=downloads&showfile=89) there's a utility function for doing it to static meshes in the nio_util.lua file. Here's the code for it: function makeUniqueMesh(ent, meshname) local orig_mesh = ent:FindChild(meshname) local new_mesh = CreateMesh(ent) for surface_index=1, orig_mesh:CountSurfaces() do local orig_surface = ent:FindChild(meshname):GetSurface(surface_index) local new_surface = CreateSurface(new_mesh) for i=1, orig_surface:CountVertices() do new_surface:AddVertex(orig_surface:GetVertexPosition(i-1), orig_surface:GetVertexNormal(i-1), orig_surface:GetVertexTexCoords(i-1,0)) end for i=1, orig_surface:CountTriangles() do new_surface:AddTriangle(orig_surface:TriangleVertex(i-1, 0), orig_surface:TriangleVertex(i-1, 1), orig_surface:TriangleVertex(i-1, 2)) end PaintSurface(new_surface, GetSurfaceMaterial(orig_surface)) end new_mesh:SetPosition(orig_mesh:GetPosition(1),1) new_mesh:SetRotation(orig_mesh:GetRotation(1),1) HideEntity(orig_mesh) UpdateMesh(new_mesh) return new_mesh end You can use PaintEntity on the mesh it returns to change the texture. Again, you can only use it on non-bone animated meshes as we don't have access to the bone information to replicate it. You could also use a special shader and a texture atlas that does a lookup based on the alpha channel. Take a look at this thread for the code: http://leadwerks.com/werkspace/index.php?/topic/607-non-instancing-copy-command/page__hl__atlas__st__20

Take a look at SetMaterialTexture (http://www.leadwerks.com/wiki/index.php?title=Materials#SetMaterialTexture) This will change the texture for all instances of that model though. There's no way to change it for just one instance of the same model if it's animated. If it's a static model then you can duplicate the mesh, paint it and hide the original.

Save the original parent in a variable and set it back before it exits? Maybe it's parented to scene or something.

I want a space monster truck! I could drive around and crush little bitty planets that get in my way.

That did it! Thanks Loomja, I was pulling my hair out trying different combinations, swizzling, etc.

Just a bump to make sure Josh sees this

Did you see this post? This is what I'm talking about: http://leadwerks.com/werkspace/index.php?/topic/1183-issue-with-normal-lighting/page__pid__10915__st__0entry10915

Try creating it in lua in the editor and turning on physics visualization so you can see what's going on.

You want both. You want the pushing force (Force) to move the object sideways, and the turning force (Torque) to rotate the body.

Force adds a pushing force, Torque adds a turning force.

K, tested, looks like it's an issue w/ LE. I don't really want to touch any other normal mapping shader code until this is resolved as I won't know which are problems with my code and which w/ LE's.