Josh

Every entity in Leadwerks Engine already is in a sparse octree.

If they're instanced, it will be fast:

Now updated to "Werkspace 2.0". I think this looks much nicer, and will help you focus on and share content more easily.

The programming sub-forums no longer allow new topics. You can still reply to existing topics in those forums. Please use the main "Programming" forum for new programming topics, and use the "Script" forum for new topics about Lua script. You may use the new tags feature to indicate if your topic is specific to C++, C#, BlitzMax, etc., if you want to. The sub-forums will be combined into the main programming forum, but I wanted to give it a test run before I commit that irreversable step.

See how easy that was?

The model editor in Leadwerks3D actually helps a lot with this because as you type in position, rotation, and scale values, you will see the entity matrix values update to match your input.

TFormVector(0,0,1,entity,NULL) returns the direction an entity is facing on the Z axis, which is most commonly the front.

Decals aren't planes. They are random unique collections of triangles extracted from a mesh. They will wrap around the edges of meshes, and conform to 3D surfaces. They are not instanced because their geometry is very unpredictable. Unless a shot is fired in the exact same position, the texture coordinates will be different. If all you want is a simple flat plane that does not wrap around edges, like the decals in Quake 3, use an instanced flat plane oriented to the normal of the hit triangle. I wouldn't be surprised if a lot of games use this, and just rely on people not noticing the inaccuracy.

That issue was resolved. The current SDK does not have the problem.

Soon.

No, I mean just make sure they are separate objects in the model file. I do this all the time to make wheels, turrets, or anything that rotates. Just use FindChild() to retrieve the entity and you're ready to rotate.

I would make each object you want to rotate around an axis a separate entity in the model. If you have two bike wheels, use two separate entities for the wheels, with their origin at the point they should rotate around.

It helps to use precise terminology. I don't know what a "group" in a model file is, since the engine has no convention with this name. Are you referring to surfaces or child entities? Why wouldn't the fan part be a child entity, with its origin around the intended rotation point? Then you would just call TurnEntity() and it would rotate correctly. Are you transforming vertices to make a surface rotate?

Then add a layer of Klepto 's dynamic clouds, and you have the best real-time skies ever invented. Are you planning to share this, or add your animated skybox in the asset store? I could help write a utility that makes blue pixels more transparent for a skybox image.

I think an alpha channel in the skybox could be used to make the sun and stars appear behind clouds instead of on top of them. I think the results would be amazing. I'm sure there's a way to calculate a simple alpha channel for a skybox. Here's something I came up with quickly in Paint Shop Pro:

You don't want SSAO to appear on bright surfaces. The indirect lighting gets washed out by the stronger direct lighting.

It uses occlusion culling on lights and animated models. You can enable it on any expensive models, as well, but if you turn it on for everything your framerate will decrease. Entity distance culling is very powerful because entities out of their visible range won't even be iterated through. You can have a million entities just out of view range, and it will make no difference. You get three different view ranges to set entities at. Small items should be "near", big ones should be "far".

It's turning out really clean and nice looking:

Drop an Environment>Atmosphere entity into the scene, edit its properties, and increase the camera range. The engine won't handle a 4096 terrain well if you increase the camera range to see the whole thing. It's better to keep the camera range lower, use distance fog, and then the engine will have no problem with that size of terrain. Terrain that is out of the camera range will have no impact on rendering speed.

Wow, that last shot is amazing. This is by far the best SSAO I've ever seen. Better than mine, and much better than Crysis. One thing you should test before you call it finished is how well it handles distant objects. I had problems with artifacts on distant terrain when I was implementing mine. I'm also interested to see how it reacts when you have contours on terrain in the distance. Will it capture that detail like in this shot?:

In the terrain panel, try setting the altitude to 500 or 1000.

Ah, that's a good illustration. I like this approach.

I mean a comparison of SSAO on and off, with diffuse and everything else enabled.

I would like to see a comparison of his SSAO with diffuse textures turned on and off.

Then it's not a normal, it's a vector. But yeah, I see what you're saying. It's surprising to me that a short vector would have more accuracy in some situations. I can't really picture a situation where a shorter vector would be more accurate than a longer one, since you will always have a greater resolution of pixels further away from the origin. That is pretty nice.