this optimizer is applied at build time, not at runtime !!
if the optimizer is not applied after change in the scene, then some geometry are invisible or pop with small camera change (often seen in WIP game). I guess the basic idea is to create zone on the allowed camera path, and keep a list of each geometry for each zone.
Anyway, when I saw your scene, on screenshot, I didn’t understand how and where you can have 2000 objects. Like others, I think you should profile and optimize your scene first.
EDIT: You’re welcome to contribute occlusion culling to jME, but It’s a very hard work (Umbra team works on it since several years). Tricks and spatial partionning is nowdays a more pragmatics approach (Source Engine, UDK, jME choose this way). But jME doesn’t give you a ready to use solution EDIT: Correction,
Source and UDK use Portal rendering
And you would have to consider all objects in the frustum to see if they are visible, right? You will have to do exactly the same calculations per pixel that the GPU is doing to render your scene… only you will be doing it the slow way.
How else would you find out what’s visible at a particular pixel? I think you haven’t really thought this through.
You keep repeating what you said and keep insisting you need to do it this way instead of explaining what you want to do (like actual game mechanics). As pspeed said, you’re probably on your own now. If you don’t believe the developers of the engine and some experienced programmers that you approach is flawed you’ll have to find it out for yourself, maybe use a few different engines and then find out what we say is actually true for all of them. Maybe then you’ll be ready to actually explain what you want to do.
I just checked my own project - 60k of triangles is the max along with particle emitters, blaster fire etc. I’m not that experienced (actually both Java and JME are just the hobby now) but I’m playing with 3D since I believe 1997, and I can say that you can create a million-faces cube in just couple of clicks (thanks to Autodesk) but effectively they’re still 12 triangles… and to drop them to that count way easier on preparation stage than to pass that million to JME or Unity and hope they will optimize it inside…
Update: that 60k are met only in extremely crowded volume, with 100+ ships which is good for debugging purposes but can hardly be achieved in a real game.
Yes, if I check all the pixels in one frame, I will be doing it the slow way, so I will check all the pixels’s 1/4 or 1/9 and they are evenly distributed on the screen, and all the needed pixels will be checked in 25 frames or more, this need test but if I couldn’t get the closest geometry faster, what I will do is not needed.
And I should get the closest geometry which is not transparent, and all the translucent geomotry should add to my render list too. And I will update the render list in every frame.
Almost all occlusion culling technology requires preprocessing the scene at build time and the algorithms are typically quite complex …
It does help a lot though, especially in indoor scenes. If you run the jME3 example “TestQ3” and then look at a wall, you will notice that a lot of geometry gets submitted even though its not seen. The GPU still has to process each batch and the vertices, and since jME3 does not perform front-to-back sorting (it does it by state instead), it could cause quite a bit of overdraw. The overhead is not cheap especially if the stuff behind those walls has complex shaders. Deferred rendering will help alleviate this a bit, and so will a depth prepass filter (which is like a light-weight version of deferred rendering).
The offline version of occlusion culling is called PVS (Potentially Visible Sets) - you might want to look into the books on the subject.
I don’t know how to deal with the single object in a batch, could you say it clearly?
As far as I know:
1, Batching means that all Geometries with the same Material are combined into one mesh.
2, Using GeometryBatchFactory merges individual Geometries into a single mesh. Thereby it becomes hard to apply specific Materials or to remove a single Geometry. Therefore it should be used for static Geometry only that does not require frequent changes or individual materials/texturing.
You shouldn’t use many different materials anyway but instead use a texture atlas. When picking you get info about the triangles and can deduce the selected object from that.
I won’t be any more specific as you still don’t say what you want to do and I don’t want to get into a discussion where its mainly about contradicting everything I say.
To batch you might have to get clever with vertex attributes… maybe store the game-logic object ID for a mesh so you can identify it again post-batching. If you need to change it’s attributes at runtime then you will have to manually unbatch it somehow and batch it into a different set.
But you don’t have many options, really, for improving performance.
I think what he wants is to do an Occlusion culling the same way games like Oblivion Elder Scrools do, not showing objects that are far away but still in the fustrung, you know, there is an option in this game to chouse the object fade distance , actor fade distance, tree fade distance, etc, I am right @ribuluo000 ?
Maybe you need to render the intire road, but dont want to render objects in it depending on the distance ?
I dont think there is some builtin solution in JM3 to do that right now thought, and its not so easy to implement.
Humm really ? There is beeping some time I dont play it, but I had the impression it simple dont render selected type of objects out of the fade distance, not only decrease its detail, I remember it is bad because if you configure actor rendering for example, at low distances, you have the impression that enemies just spaws at your face when you are walking into the terrain…
Anyway, its an complex discussion, needs more information about what he wants.
I have a felling that he wants to render selected objects in defined ranges, but who knows.
Just saying I want to render what the camera can see dont say anything…
It is still a different technique. What you describe would cause popping as objects get within the threshold or outside of it. Occlusion culling attempts to determine by some means (build time or runtime) that an object is obstructed by another object and therefore is not visible and should not be rendered, hence there’s no visual artifacts or popping with occlusion culling.
