Hi!
I see that some people here would like to create a First Person Shooter and there is no build-in support of any spatial subdivision system in JMonkeyEngine 2, there are only unofficial projects proposing BSP, octrees and mine is related on both cells-and-portals subdivision and portal culling.
Of course, it is possible to create a game with the existing features of JMonkeyEngine 2 but I claim that huge indoor environments with lots of graphical elements can noticeably benefit of cells-and-portals subdivision and portal culling, even my crappy level (only simple orthogonal walls, 500000 vertices) is drawn a lot faster (11 FPS without cells-and-portals subdivision and without portal culling, close to 68 FPS with only cells-and-portals subdivision and existing frustum culling, close to 75 FPS with both cells-and-portals subdivision and portal culling = the same frame rate than glxgears on my machine) with my method.
I have to work more on my new feature to fix the last bugs (the portal culling is not working, the collisions with portals are not accurate enough, the portalizer for orthogonal axis-aligned walls works but not the general portalizer for any geometry) and I would like to know whether people are interested in using it in order to decide whether I have to plan a real integration in JMonkeyEngine 2 (or 3?) or I keep it separately. For the moment, the only new public class exposed by the API and used directly in the scene graph is compatible with the way JMonkeyEngine 2 handles nodes, spatials, etc… there is no need of changing everything to use it in your projects. Let me know if you're interested.
I'd say go for it, it would be useful to a lot of people, but you say it won't require changes to existing code, which would allow folks to drop it if they don't want to use it, or replace it with their own implementation, which is good in my book.
Starnick said:
I'd say go for it, it would be useful to a lot of people, but you say it won't require changes to existing code, which would allow folks to drop it if they don't want to use it, or replace it with their own implementation, which is good in my book.
For the moment, the public API introduces only one new kind of node. The only necessary change consists in using the method attachDescendant(Spatial spatial) instead of attachChild(Spatial spatial) because a child of an instance of the class Level is an instance of the class Network whereas an object handled by an instance of the class Level is indirectly attached to an instance of the class Cell. However, the final user does not have to know all these implementation details in order to use this.
The other change is the necessary preprocessing. This step requires too much memory to be done during the execution of the game. However, updating the existing cells and portals will be possible at runtime.
This sounds extremely interesting…
Would an open area really benefit from portals and cells though (beyond frustrum culling)? Still a great idea.
Great idea!
msj121 said:
This sounds extremely interesting....
Would an open area really benefit from portals and cells though (beyond frustrum culling)? Still a great idea.
Actually, I will use antiportals (big occluders) and other methods in open area to keep a good frame rate. If you have any suggestion, let me know.
I have no Internet connection at home, I will get it back in some days. I'm sorry for the late reply.
Currently, I am testing the modifications done on the collision tests.
I am absolutly interested in this and I think JME need it. If you'll need some help just send me pm.
[quote author=[IR]Radek link=topic=11607.msg88376#msg88376 date=1249560617]
I am absolutly interested in this and I think JME need it. If you’ll need some help just send me pm.
[/quote]
It is a good piece of news. You can already have a look at the source code. It is a bit hard to generalize my algorithms, look at the class jme.portalizer.Portalizer, there are some missing steps.
Poisonville already uses a complete implementation of portals, it would be fine if you convinced their programmers to share their source code or at least some algorithms.
The portal culling has a bug. You can set a flag to true to re-enable it, the debugger will then display the portals directly in the 3D world.
I will be more productive when my ISP gives me back my Internet connection :’(
Where’s the source located?
Nvm Found it heh, I missed it in the tuer svn 
Hey you all,
Since I'm making an indoor game, I implemented the cell-and-portal algorithm for my Game…
currently it doesn't support occlusion culling.
I tested it on my PC (intel-quadcore @ 2.67 GHz and HD4870 }:-@)
and my scene (Two Cells with one Portal between them and 3 ~100000 Vertices Models)
it renders with 1.1k Frames when you only see one Cell, 350~400 when you see Both.
Without cell-and-portal the scene renders with 350~400 frames, not depending on where you are.
I think i will implement Occlusion Culling until tomorrow…
Any feedback welcome,
Tim8Dev
Okay, Occlusion Culling is implemented now, but not yet tested,
I think it should be integrated into JME2 (or 3). ( It's just 4 Classes, user just need to deal with 1 Class!)
So should I re-post this in Contribution-Depot?
feedback welcome.
Tim8Dev
tim8dev said:
So should I re-post this in Contribution-Depot?
+1 I would really like to see this added to JME 2!
EDITED:
For further discussion on MY implementation please go ahead to
-> jME2 > Contribution-Depot
For discussion related to the implementation of GOUSSEJ please stay here
I go on working on my implementation!
I'm sorry!
Go on please!
Btw… Do you reduce the size of your frustum through a portal?
tim8dev said:
I'm sorry!
Go on please!
Btw.. Do you reduce the size of your frustum through a portal?
I tried but it is not working properly for the moment whereas the debugger shows correct portals.
I have to explain something once again. I suggest a all-in-one solution, you take your existing levels without any change, you use the portalizer to precompute the geometry and you load the resulting geometry into your game by using the importer. If several people implements the same feature differently, it is only a waste of time on my view.
I have to explain something once again. I suggest a all-in-one solution, you take your existing levels without any change, you use the portalizer to precompute the geometry and you load the resulting geometry into your game by using the importer. If several people implements the same feature differently, it is only a waste of time on my view.
Okay, so I thought about it, but I need an Implmentation for my Game and so I first want the core features implemented.
How you then generate from a given Level/Spatial, is another question and currently I'm not need them.
For the moment, I will port my source code to Ardor3D.