I have a large Scene and put some effort in dynamically optimizing the scene with attaching and deattaching objects fro the scene. Now I have a question, probably concerning understanding more than a problem:
In the StatsView i have an object count of about 1300, but counting the amount of Geometries using Util.getAllGeometries(rootNode).size() gives m a totally different amount, arround 300. I guess, that the Image Textures are rendered as separate objects, but even when baking all geomtries to a texture atlas, with 300 Geometries in the rootNode, I should be getting 600 Geometries in the openGL Pipeline, correct?
Where is my thinking mistake? Why ist there such a large difference? I thought the objects counted in the stats view are the geometries currently rendered by OpenGL?
Maybe you have lights? Every object is rendered once per light. Also don’t forget about the UI etc., thats geometry too.
yes, thats it. Sorry, I should have known that
yes, thats it. Sorry, I should have known that :)
JME uses forward rendering, so once per light is rendered,
IT is posible to create a own lighting shader, that could use for example 8 lights, and add a system that passe it the most relevant lights. Then you could do the calculation for all 8 in one pass.
-> However this is boviously limited to usecases, and not usefull for everything
Defered lighting is not in jme yet, however several persons are working on different approaches with it. It works by calcualtion in screenspace and is way superior in performance but cannot handle transparent objects very well.
okay, thanks. I will probably just bake the shadows and Lights to the texture in Blender, that way I only need one ambient light. One last Question Though: Would there be a way to apply a light only to certain objects in the scene, i. e. by distance of the camera? That way I could use one ambient light on all objects, and the directional Light on the close by objects.
A light only affects objects below it in scenegraph,
I did some test some time ago
1 ambient + 100models with 1 directional light each are as fast as
1 ambient + 100modles with 1 global directional light.
So if you do the increased managing overhead, to add a level a lightnode management to your game, you can have far greater lighting details without a increased rendering cost.
Ill let someone else answer this more fully (I dont know if you can do what you want with the directional light) but almost all AAA games disable point lights and spot lights as the player moves further away from them, reducing intensity until they are judt removed. If you have many lights, this could be a really good way to improve performance.
@EmpirePhoenix Do you know if its possible to do something like that with shadows as well? I think its a waste to have the renderer be drawing shadows that are very far away from the player (and likely wont see amyway)
If you use the normal shadow renderes, you can set a maximum distance, and set them to fade out gradually.
I guess the DirectionalShadowRenderer already has a possibility to set the shadow distance? dlsr.setShadowZExtend(distanceFromCamera);
Is that what you mean?
Oh yes sorry. I should have looked at the docs before posting.
One last Question: I have a skyline that should be visible from a far distance. So I have to set the frusum_far of the camera to very far. That seems to slow down the scene although the skyline itself is a very low poly object with very small texture. For Test, I placed the skyline just in front of the camera, and set the frustum_far to a lower distance. This for some reason ist faster, although the amount of objects loaded is the same.
1: Does a large camera frustum always come with lower performance, although the object amount is the same?
2: Does anyone have an Idea, how to exclude the skyline from frustum culling, so I can set the camera frustum to a nearer distance but still see the skyline? Like an option to exclude certain objects from frustum culling?
You could do serveral things:
1 3d Skybox
Have a second scene in a second viewport, render it first, as background
Then render your normal scene above it.
-> Works similar to skybox but in another full rneder pass allowing 3d objects
Have a secondary scene, and render it to a skydome (eg using a 180° cam), use the created texture for skybox, update when moving fast/ necessary
-> Nearly no cost, if skybox is only updated at low rate
- Skale/fake objects,
eg instead of drawing at 2km distance draw at 200m distance and scale it smaller so it looks as far away as before
-> kinda free, but must take care that objects do not overlap.