I’m referring to moving an object itself. Player for example. I’m not referring to lights in any way.
This seams like it will be slower then my system. You would have to go throw all the lights for each spatial as well as all the nodes. In my system all you have to do is updating the lights for the spatial that are in view. Even if you one day want to implement your system it dose not make my system useless.
If I understand you correctly, your scenegraph looks like
State → City → House → Monster → Torch → LightNode
The monster carries the Torch around the House. When he leaves that house to get to the next House, you want to detach the monster from his original House and Attach him to the new House. When we do that, we have to tell his Torch’s LightNode to now affect things in the new House, as well as any houses adjacent to his new house. In this example, won’t we still need to change what Light’s affect? Or is your scenegraph different?
As I was saying, in cep21 example would you would need my system to handle all the lights that may be in the hose. Let say you have 16 dim lights in side the hose, It would be a bad idea to diveid the hose into 4 parts. You can use what you are describing to divide the lights down to a fue but once you divide them you may still need my system to do the rest.
I can appreciate what you’re saying, but it seems like you’d still attach the light to a node attached to the torch… Then your code (as a utility external to the scenegraph) would be called when such rearranging of lights are needed… for example, when walking through a portal such as a house door. The code would assign the lights to their appropriate lightstates based on whatever logic is defined in the utility.
"renanse" wrote:
(as a utility external to the scenegraph)
Can you explan what you mean?
I think he means that the problem of changing which lights affect which nodes should be left to the game creator and should be seperate from the SceneGraph of jME because it can be very game dependand as far as knowing when to update Light positions.
It would be very hard to do that because the code must be in update to work, the only way I see to do that is have a call back in lightstate that is called every time apply is called.
I do not see how It is application dependent, my code determines how much a light would affect a spatial and uses the one that would afect it the most.
let me expand more on mojo’s remark with the fire:
Say you have two rooms, beside each other. One of the room is a dark horrible room with no lights, because the electricity has been cut off. The second has a nice little fire in the middle of the room. Now you want to attach the light to the fire room, because if you attach it to the rootNode, the dark room will be lite too. And you dont want that because in the specifications, its dark!
With me badmi?
DP
"DarkProphet" wrote:
let me expand more on mojo's remark with the fire:
Say you have two rooms, beside each other. One of the room is a dark horrible room with no lights, because the electricity has been cut off. The second has a nice little fire in the middle of the room. Now you *want* to attach the light to the fire room, because if you attach it to the rootNode, the dark room will be lite too. And you dont want that because in the specifications, its dark!
With me badmi?
DP
Say you have two rooms, beside each other. One of the room is a dark horrible room with no lights, because the electricity has been cut off. The second has a nice little fire in the middle of the room. Now you *want* to attach the light to the fire room, because if you attach it to the rootNode, the dark room will be lite too. And you dont want that because in the specifications, its dark!
With me badmi?
DP
I understand the problem with attaching the light node to the root node, I meant that for simple demos. In the fire demo you would have seprit lightstates in the rooms. My system would be used when you have more then 8 lights in the same room, it will decide which light to use for, in a example, the table, each wall and the person inside. You will still need
the other system for advanced seans like this one but using my system with the other would speed it up.
Well, while I believe there is a better way to handle this, I haven’t offered any alternate solutions. So, I’m going to defer to Cep and Renanse. If they approve it, I’ll put it in (once it goes through the review process of course).
I’ll defer to renase. He’ll know more about this area.
My point about it being a seperate Utility is basically that if Badmi feels he has a usable algorithym for reassigning lights across a scenegraph based on certain criteria (such as location for example) then he could easily write this in a utility form. You pass in the scenegraph to be updated and the lights are rearranged / reassigned as needed.
As for access to the update methods, are you saying you need to implement this directly in the updateXX methods of Spatial? If so, then please explain why because it seems unnecessary. The utility class could be called when necessary, such as once per 100 frames, or whenever you step through a portal (I assume you know about portals) or when certain distance boundaries are met, etc. That part would be left up to the programmer to implement although examples could be written to assist.
Anyhow, obviously my opinion. I have yet to hear exactly what core code you feel needs touching so maybe you could explain in a bit more detail…
I need the code called from the apply function of state. Apply is only called on when a Spatial is going to be rendered. The code is fast, so it is able to be used when there are many spatials on the screen, but it would be inefficient to be used on all the spatals in a large Tree when only a few need to be rendered.
Changing the states themselves is a major deal. Why do it there? When calling it from somewhere else as I described, speed is not an issue if you control how often such a call is made.
Renanse is right on. You should not require any changes to the light states themselves, but provide a way to build these states from a utility. I.e. supply your utility with all the lights you want to use, and have it build the required lightstates (with the 8 lights that are relevant to the nodes), placing them in the scene graph.
I do not see the problem with changing the state being that the modifications would be fully optional. I think I can do it without modifying the state if there is a way to access frustrumIntersects in spatal.
Sorry, I just don’t see the reason. Maybe you can share the code you are working on or a diagram of it?
Badmi, if you take a collection of lights (the user can just dump them into your tool), the they supply a scenegraph, could you not then create the lightstates as needed? There is no reason to check this every frame. The scene will not change fast enough to ever require a check every frame.
Meny games have moving spatial that move pass different lights (take a look at splinter sell). For a static tree then what you said would be fine but if something is moving then you would need to have the ability to resort the lights. Just look at the code I posed before.