Beyond thinking that I read somewhere on these forums that jME currently doesn't do "indoors" well at this time (from what I assumed at the time was due to model boundary issues), I found that when looking at model boundaries in SimpleGame on simple models (say a sphere inside a bowl – bowl as parent, sphere as child) I found that there were individual boundary boxes around both the sphere and the entirety of the bowl (or so it appeared). So, I thought, well then – maybe I can build an enclosure model (something simple like three walls and a half roof) in four parts and parent them all together and then individually setModelBoundary() on each piece when loaded in jME and thus use hasCollision to detect if a player has collided with a wall while also leaving the interior space open for movement. So, I designed a test model (not the enclosure) to test this idea and it seems that while individual model nodes get individual bounds the entire model is also bounded. I, of course, tried a model with parent/child relationships and without. Here's a pic (as if it's necessary) that was the same in either case:
http://picasaweb.google.com/ashtonv/Dev/photo?authkey=Oh1EbQR_zJI#5138474120554102930
My question: is there a way to do away with the entire model boundary and leave the model node boundaries intact? If not, what is the best way to work with enclosures (the ray-intersection way of doing things)?
Two comments:
- The remark of jME not being able to handle well indoors was made on a very specific context, in which the outdoors are still maintained in the scene, and jME is unable to perform view occlusion dynamically to decide whether an object is seen or not... It only perform frustum intersection/inclusion for that.
- The hierarchical creation of boundaries is required for the algorithm of frustum intersection to work. That way it can ignore sections whose parent nodes do not intersect, while recursively traversing those that do.
Hope this clarifies the issues. ;)
duenez said:
Hope this clarifies the issues. ;)
It does clarify the issues. Thanks.
Over to an evolved question (in two forms this time): 1) what is the best way to construct a model/node-series for an enclosure (or partial enclosure) and interact with it's boundaries in an outdoor scene (perhaps something like procedurally built invisible shapes with boundaries that are attached to model nodes?), and 2) likewise for an enclosed building interior where some part of the outdoor scene can be viewed from inside (such as creating the illusion of the outdoor scene using a skybox around the model with prerendered shots of the directions in question?)?
Or would using ray intersections be better?
For the indoors case, using a Skybox as mentioned would be fine… You can even use the RenderToTexture to build your box faces automatically after you enter your indoors scene, and then just use that same box throughout the scene (it is just an approximation after all), or update it every second or so.
For the first one, I don't understand what you mean, but I can tell you that you can indeed create invisible meshes setting the culling mode of the spatials to cull always… they would still be processed by the bounding hierarchy that way.
duenez said:
For the first one, I don't understand what you mean, but I can tell you that you can indeed create invisible meshes setting the culling mode of the spatials to cull always... they would still be processed by the bounding hierarchy that way.
Was "procedurally built invisible shapes with boundaries that are attached to model nodes" the confusing part?
If so, let me see if I can explain better using an example.
Say that I want a building in an outdoor environment that has an awning/overhang on it and I want the player to be able to explore the area under the overhang. Applying a model boundary to the entire building model would not work with hasCollision to prevent the player from running through walls, since that boundary would also enclose the area under the awning. So, what I proposed was using (now in corrected language) cull-never shapes with boundaries attached to specific parts of the building's nodes (walls, awning posts, awning roof, etc) and using them to test for player collision. My question as stated in the quote above was trying to get at possibly a way to attach those cull-never boundaried shapes programatically to the model instead of manually attachnig them. Something like this might look like:
* feed multi node model to boundary setting function
* boundary function examines model nodes
* based on a node test (against node name?): function determines node shape, size, orientation, location and builds a boundary shape and flags it as collidible and stores it in a collision array for later processing
* attach cull-never boundary shape onto the scenegraph
* during play, the hasCollision for the player would be tested against elements in the array
I guess that the largest question in the above is how to get a nodes shape, size, orientation, and location to properly build the cull-never boundary shape. I can also see a processing hit if the collision array is monstrously huge. Of course, this would only be for static objects.
Have I cleared up or further muddied the waters? ;)
Erp, in my post above change all "cull-never" to "cull-always"…
IMO, what you want to do is already done… Bounds are computed automatically, and thus, if you could have a multi part model (building = building_body + balcony + etc), then you would only add to the collision test the more basic objects (components of your logical objects). And they would have nicely behaved bounds, because you designed you model components that way. Like this, you don't need any invisible meshes, but you can still have them if you want.
Obviously making it programatically is possible, it is just a case of designing you models accordingly (by name?)
Hmm… I guess I might have been overthinking this. If one can set boundaries on and collision checks against sub nodes in a model and skip the root node of the model, then there is no need for the invisible shapes with boundaries that I was talking about – they were envisioned only to get around what I thought was the unavoidable collision boundary of the model's root node. I will look further into this. Thanks.
And yes, I was thinking about a node naming convention to identify nodes that are collidable or have other special properties.