In case it wasn’t said yet, simply looping through all objects and determining the distance to the camera (object.position - cam.position).length is definitely the quickest solution. Otherwise, as was said already, jME already culls everything outside the frustum, so simply setting the far plane of it would do what you want. (While as said, you might have to cut down on the actual object count anyway). Ray casting is definitely completely overblown for that purpose.
There is a technique called Occlusion Query that can reduce draw calls on crowded scenes.
IMO it’s not really worse the hassle, because it has some nasty draw backs and most of the time a good way to batch partition your scene will yield better results…
IMO, from the screen shots, your scene could be less than 30 geoms if properly batched (not counting the UI)
Did you try that approach?
1 Like
By default BatchNode will use double the RAM because it keeps the originals of all geometry as well as the batched copy. I never said to use BatchNode. If you don’t keep the original copies around then they will get GC’ed after you batch them… then only the batches exist.
The only time memory increases in that case is when you are batching multiple instances of the same thing… but those should be small anyway and just the lack of having separate Geometry + Mesh objects might make up the difference.
…even better is if you batch before you even load the data and then load it already batched.
So the user can paint the whole level? I don’t understand this requirement.
1 Like
If I don’t understand error, what you mean is reduce triangles of the geometry rather than to render less at the runtime, is it?
If you want to find the closest geometry to cull it, it means you want to don’t render objects that are far away from you? If that’s the case, you could reduce the far frustum plane:
cam.setFrustumFar(1000f); /*1000 is default, play with lower values.*/Yep, exactly. If you get the same visual result why to pay more.
Yes, it’s a solution, maybe it’s not a good solution just like what you said. In this case, if I want to look my scene far from the center, I couldn’t see anything because of the far plane is too near. I did a test about this, maybe there is other better choice, which is I’m looking forward to.
I once batched some geometry and when I use ray-cast to get the closest collision, I got the whole batched node, and I set the closest geometry’s color red and the whole batched node became red, it just like what I clicked is not what I want, because they are batched in a node.
It looks abnormal, could I get the right geometry that I want rather than the whole node? I’m worried about it.
ie:
Does every object in your level need to be selectable?
If so then you are screwed no matter what you do… if they can select the individual white lines on the road then you are in trouble.
Else it’s a fake requirement and stop worrying about it. Let it go.
1 Like
Ok, I’m in trouble now, and I have a big scene and all my geometry in the scene need to be selectable.
And I found that to get the closest geometry is very important for me. If I can get the closest geometry, maybe all the trouble would be solved. If I can get the closest geometry, I could only render the geometry that I can see and if needed I will batch some geometry that vertices is less than 200, it must could make my scene perform well; And if I can get the closest geometry, I could change the material of the geometry includes the color and I will not worry about it. Now that there is no such a solution to get the closest geometry, I will try my best to write it out, it must be a hard work I think because I have no idea about it now, but once I write it out, I will share it to the hub.
@pspeed @Momoko_Fan, @Torsion, @nehon, @afonsolage, @normen, and @ all the people who contribute to the JME, the JME is a great work, thank you anyway, lovely people!
What do you think getting the closest geometry will do for you?
YOU ARE ALREADY ONLY RENDERING WHAT CAN BE SEEN!!!
The frustum culling only renders what’s bounding box is in the view frustum, ie: what can be seen on screen. Unless your bounding boxes are ridiculous but I already covered that, you haven’t checked, and I’m done repeating myself.
So you either have a different definition of “seen” or something else is not being communicated correctly.
Good luck with your game.
Also, what is the reason you need to select each individual one of the 2000 geometries in that first screen shot? You may need to explain what you are doing for real.
I think he means occlusion based culling but doesn’t really realize it takes more info than whats closest. @OP, if something is closer to you than something else that doesn’t always mean you don’t see that other thing anymore.
As for having each geometry selectable I also think thats an illusion, having an info where in the scene a picking occurs should be enough, even if you wanted to replace the single object in a batch then (e.g. for an editor).
1 Like
Yeah, if that’s what he means… that’s occlusion.
The only way to get proper occlusion information is to actually render the scene. Even occlusion queries would require rendering the scene at least once.
So far the requirements seem pretty impossible for a mobile game.
First, I think getting the closest geometry will help me to render objects as less as possible, in this case, there is no need to render every objects in the frustum,
for example: there is a long wall in the frustum and many small objects after the long wall in the frustum, so I couldn’t see the many small objects even if they are in the frustum, so if I got the closest geometry I will only render the long wall rather than all the objects in the frustum, simply say I will keep all the geometries that I can really see in the collection and I will update the collection in every frame, the objects in the collection is not a lot we have had a test in unity by the way. That’s why I always say that the frustum culling is not enough for me. And
if needed to batch some little geometry I will do it just like the unity.
Second, why I think getting the closest geometry is necessary is that
because I got the handle of the geometry so even if it’s batched, I can change the material of the geometry, isn’t it?
All the objects in my scene should be selectable, and I should know which geometry is selected, and I want to look the relevant infomation about the selected geometry.
Yeah, maybe, but what I want is a fast method to get the closest geometry and no need to do other things.
Yes, you are right, so I need to send the ray nearly full of the screen to get all the closest geometries, in this case, I will get all the objects I could see, that’s why I need to get the closest geometry faster.
Seriously, I see nothing on the screenshots that would really worth 300k triangles. Probably you start optimizing in the wrong place.
With all these “requirements” you need to seriously re-think your approach. Maybe we could suggest something if you were actually saying what you want to do instead of insisting you have to do it this way.
Considering an endless road, you could use, say, three-level LOD using simplified objects and/or textures at distant points without major changes to the code. We can theorize endlessly unless you provide us with the overall task that needs to be achieved.
We keep asking why you need this and you just keep repeating it. So whatever. Are you writing a game or a level editor? We can’t help you navigate the impossible (and what you want is impossible) without knowing ways to suggest alternatives before they just get shot down again because you won’t explain what you are really trying to do.
I understand now that you think you want to cast a ray for every pixel on the screen to see what’s visible. Note that this is already what the GPU is doing when it renders and it’s doing it faster than you ever could… by orders of magnitude. So if you are only getting 4 FPS rendering, expect to get 0.0004 FPS trying to ray cast every pixel.
So, unless you can find a way to explain what you are really trying to do then there is no way that we can help. Your current approach is impossible and all proposed alternatives have been swatted down. So I guess you are on your own.
1 Like
I don’t agree what you said about the GPU, and the GPU will render all the objects in the frustum even if the objects are after the long wall. Maybe my scene is special, but that’s it. Ps:
If I could only render the objects that really can be seen, there are only a few objects should be rendered, because most of the objects in the frustum will be blocked, and I couldn’t see it in the frame so if I don’t render them and in my scene I think it’s necessary for me, there will be a good performance.
I have said something about my scene, and you should know my scene is very big and there are many geometry have the same mesh, and if only use frustum culling it’s not enough for me, because there are still many objects in the frustum I will see the scene far from center sometime then all the bounding box will be in the frustum if only use frustum culling this will be the worst case.
My camera is very flexible, it can rotate up, rotate down, rotate left, rotate right, and rotate around a point up, rotate around a point down, rotate around a point left, rotate around a point right, and move forward, move backward, move up, move down, move left, move right, because I want to look the geometry in the scene in every direction.
And I want to learn the geometry’s detail information, so it must be selectable.
That’s what I want to do, if you want to know what I want to do clearly, maybe you should to learn something about the app “BIMx”, the basic function is refer to it. Something about “BIMx”:
Thank you very much!