fxStarField implementation quandries..
by Jonathan Tarbox · in Torque Game Engine · 09/15/2002 (8:11 pm) · 10 replies
Ok, going along the idea Melv gave me, I'm creating the starfield I was going to do with fxLight's into a single fxStarField object. We're talking, at least with my data, of about 16,500 stars in total. Now, the issue here is kinda weird. I can do a starfield in torque in two fashions:
1. Have the fxStarField object load in a data file and automatically create fxLight/fxSunLight objects for each star, letting the torque engine handle all the culling. Only really need the flare effect for what I visualize, so if fxLight is used the Light itself can be turned off.
PRO - Stars will be Torque objects themselves, thus Torque stuff can be done to them (selection, editing, etc..)
CON - That's a lot of objects, and most engines can have trouble dumping that many into them.
2. Have the fxStarField object load in a data file into it's own built-in octree and when it's renderObject() is called, have it parse through the tree for visible stars and render each one. I've done this in Crystal Space and believe I can easily port my octree over to Torque.
PRO - The octree system would likely speed up the visibility culling as it'd be optimized for just this.
CON - Each of the stars would not be a Torque object, but one solid object of a bunch of stars. So features like selecting a star wouldn't work so well.
Now, the real questions I guess...
- How many objects can Torque handle? Is there an upper limit?
- In Crystal Space I used the camera object info to setup a csFrustum object.. but I don't really see any usable frustum objects in Torque. The only thing I see that I think I could use is dglPointToScreen() as it returns a boolean value which should tell me if the point is on screen (it uses gluProject() to do it)
I'd like to be able to select the stars individually, but I think that if I did the second option that I'd have to get really funky with selecting what's on screen. Only problem is that the second option is probably 10x better then dumping 16k objects into torque.
So, anyone have any opinions or ideas of what Torque can or cannot handle?
-jtarbox
1. Have the fxStarField object load in a data file and automatically create fxLight/fxSunLight objects for each star, letting the torque engine handle all the culling. Only really need the flare effect for what I visualize, so if fxLight is used the Light itself can be turned off.
PRO - Stars will be Torque objects themselves, thus Torque stuff can be done to them (selection, editing, etc..)
CON - That's a lot of objects, and most engines can have trouble dumping that many into them.
2. Have the fxStarField object load in a data file into it's own built-in octree and when it's renderObject() is called, have it parse through the tree for visible stars and render each one. I've done this in Crystal Space and believe I can easily port my octree over to Torque.
PRO - The octree system would likely speed up the visibility culling as it'd be optimized for just this.
CON - Each of the stars would not be a Torque object, but one solid object of a bunch of stars. So features like selecting a star wouldn't work so well.
Now, the real questions I guess...
- How many objects can Torque handle? Is there an upper limit?
- In Crystal Space I used the camera object info to setup a csFrustum object.. but I don't really see any usable frustum objects in Torque. The only thing I see that I think I could use is dglPointToScreen() as it returns a boolean value which should tell me if the point is on screen (it uses gluProject() to do it)
I'd like to be able to select the stars individually, but I think that if I did the second option that I'd have to get really funky with selecting what's on screen. Only problem is that the second option is probably 10x better then dumping 16k objects into torque.
So, anyone have any opinions or ideas of what Torque can or cannot handle?
-jtarbox
#2
However, I need for players to be able to select a star and do something (travel to it, get info, blow it up, etc..). I don't know.. I kinda need to find out the limitations of the engine first I suppose.
-jtarbox
09/16/2002 (12:03 am)
Well, in your image there you're camera is at a fairly finite point not trying to allow navigation across the galaxy.. the stars you use are more of a background effect then anything, so that's quite feasable to do em randomly and jam em all up there.However, I need for players to be able to select a star and do something (travel to it, get info, blow it up, etc..). I don't know.. I kinda need to find out the limitations of the engine first I suppose.
-jtarbox
#3
First of all, trying to create a general metric on what the Torque can handle is difficult if not impossible. Perhaps a better way of asking the question would be what are the limitations of the computers of your target audience?
Obviously, the least amount of 'objects' the better so putting this into a single object is best. Doing frustum culling is fairly easy, an example of which you can find in my fxFoliageReplicator. The way I would check the star selections would be the other way around. Being as you are going to compile a list of stars for rendering then you may as well reuse this as a list of stars to check against a mouse selection using the screen projection function you mentioned.
- Melv.
09/16/2002 (1:26 am)
Johnathan,First of all, trying to create a general metric on what the Torque can handle is difficult if not impossible. Perhaps a better way of asking the question would be what are the limitations of the computers of your target audience?
Obviously, the least amount of 'objects' the better so putting this into a single object is best. Doing frustum culling is fairly easy, an example of which you can find in my fxFoliageReplicator. The way I would check the star selections would be the other way around. Being as you are going to compile a list of stars for rendering then you may as well reuse this as a list of stars to check against a mouse selection using the screen projection function you mentioned.
- Melv.
#4
-jtarbox
09/16/2002 (9:05 am)
Hmm.. could I indeed use that function in reverse? But then how would it return the proper depth of the object.. I'll look at your foliage object to see how it's done.-jtarbox
#5
Well, you would have to calculate which stars are in the frustum anyway so why not re-use this list rather than parse it again to calculate whether any are projected where your mouse is clicked?
I created a class which has more functionality than you will need here but shows you frustum culling in action. Have a look at the fxFoliageRenderList class, particularly the SetupClipPlanes function followed by using a version of the IsQuadrantVisible function. My version iterates through the quad-tree but you won't need any of that. A version of these two functions should do the trick.
- Melv.
09/16/2002 (9:16 am)
Johnathan,Well, you would have to calculate which stars are in the frustum anyway so why not re-use this list rather than parse it again to calculate whether any are projected where your mouse is clicked?
I created a class which has more functionality than you will need here but shows you frustum culling in action. Have a look at the fxFoliageRenderList class, particularly the SetupClipPlanes function followed by using a version of the IsQuadrantVisible function. My version iterates through the quad-tree but you won't need any of that. A version of these two functions should do the trick.
- Melv.
#6
09/16/2002 (11:41 am)
James: care to share that as a resource?
#7
If you are making some sort of real astronomy game which involves a lot of looking at a lot stars from a fixed point, then I guess I see where you are comming from. However, if you aren't, then I'm confused.
Here's my question: Are you making a STARFIELD or a GALAXY?
Here is the deal the way I see it. If you want to select stars, then you wouldn't want 10000+ of them right? I mean, that just doesn't make much sense. Player's dont need that many points of information, nor could they actually use them. So if you were making some game that involved selecting stars I'm guessing you'd want just like 20-30. If you just want a pretty starfield with 16,000 stars, then selecting them doesn't matter.
And if you wanted to make a simulated galaxy or something, why not actually make it take up space, ie, be a shape which the player can move around in. But that would only be good for like some sort of space empire game, and even still you'd probably only want 100-200 stars MAXIMUM...
09/17/2002 (7:04 pm)
Perhaps I am absolutely not understanding you at all, but I think you should think about the requirements here.If you are making some sort of real astronomy game which involves a lot of looking at a lot stars from a fixed point, then I guess I see where you are comming from. However, if you aren't, then I'm confused.
Here's my question: Are you making a STARFIELD or a GALAXY?
Here is the deal the way I see it. If you want to select stars, then you wouldn't want 10000+ of them right? I mean, that just doesn't make much sense. Player's dont need that many points of information, nor could they actually use them. So if you were making some game that involved selecting stars I'm guessing you'd want just like 20-30. If you just want a pretty starfield with 16,000 stars, then selecting them doesn't matter.
And if you wanted to make a simulated galaxy or something, why not actually make it take up space, ie, be a shape which the player can move around in. But that would only be good for like some sort of space empire game, and even still you'd probably only want 100-200 stars MAXIMUM...
#8
09/17/2002 (7:42 pm)
it is a galaxy, and in fact it is THE galaxy. I'm taking my data directly from NASA archives. It is a "space empire game".
#9
Sounds very cool, I like the NASA data idea. This definitely requires something with more solid star objects. You wouldn't really have much of a choice on this one.
Using 16,000 stars brings up a lot of interesting problems.
One is Helping the player differentiate between stars, since they all probably look similar. This isn't that hard with a HUD.
The other serious one is overlapping or just general clutter from situations involving looking down the galaxy fromone end to the other, or far out views. You would need some sort of depth restriction on selecting, which could also be a performance improvement.
This is actually a pretty interesting idea. Perhaps a system with a lot of different view styles? Like a camera, a top-down, or a perspective?
and while this is a field of stars, it's not really a starfield in the decorative backdrop sense (I imagine the enterprise at warp speed here), which is what I think of when I hear "starfield". Perhaps I am wrong in thinking this way.
Also.. if you went with the built in array of stars (the octree idea) you COULD do selecting, and you could do a function that interprets the star position for game-object usage. It might seem strange in the game at times, depending on how it is done. I'm not sure about how well 16,000 objects would go over in Torque.
09/19/2002 (6:22 pm)
Hmm.Sounds very cool, I like the NASA data idea. This definitely requires something with more solid star objects. You wouldn't really have much of a choice on this one.
Using 16,000 stars brings up a lot of interesting problems.
One is Helping the player differentiate between stars, since they all probably look similar. This isn't that hard with a HUD.
The other serious one is overlapping or just general clutter from situations involving looking down the galaxy fromone end to the other, or far out views. You would need some sort of depth restriction on selecting, which could also be a performance improvement.
This is actually a pretty interesting idea. Perhaps a system with a lot of different view styles? Like a camera, a top-down, or a perspective?
and while this is a field of stars, it's not really a starfield in the decorative backdrop sense (I imagine the enterprise at warp speed here), which is what I think of when I hear "starfield". Perhaps I am wrong in thinking this way.
Also.. if you went with the built in array of stars (the octree idea) you COULD do selecting, and you could do a function that interprets the star position for game-object usage. It might seem strange in the game at times, depending on how it is done. I'm not sure about how well 16,000 objects would go over in Torque.
#10
Firstly, I take the entire data and dump it into an octree, based upon location. Default stars per node can vary.. 100 is decent performance, while 50 is a hair faster but a little more memory intensive, etc..
Secondly, I need to create a frustum culling system that updates with the view. Melv already has code for this in fxFoliageReplicator and I am using a good chunk of it. I knew how to create one and use it, but I didn't know how to pull the information from Torque.. that's where Melv's code came in. This frustum is created with a far clipping plane, thus there will be depth culling which can be a system varaible.
Now, while I can draw bright stars farther out if I so choose, but it would hamper the selection feature. So, I'm going to make like a wireframe s[here feature to signify the outter edge of the view (just so it doesn't look so dumb with the universe dropping off...)
As for mouse selection, it's not hard at all. Just take the mouse coords and compare them to the current screen coord's of the visible stars, which I'm storing with the other star data. Yes, this means the star data will contain world coords and screen coords, but it's the simplest way to do it.
At present, I'm more or less stuck on building the object which can be loaded in a mission then the octree. Doesn't like my object, gonna dupe fxLightDB and alter it as my next attemot. I've already used this octree code in another application, so I'm fairly confident is should work well. The other application was a test of the octree system within the Crystal Space engine (http://www.crystalspace.org in the contest section, it's called PI)
-jtarbox
09/19/2002 (8:09 pm)
hehe It's not as hard as you think. I am going with the octree system as I figured out how to calc a selection (thanks to Melv.) Firstly, I take the entire data and dump it into an octree, based upon location. Default stars per node can vary.. 100 is decent performance, while 50 is a hair faster but a little more memory intensive, etc..
Secondly, I need to create a frustum culling system that updates with the view. Melv already has code for this in fxFoliageReplicator and I am using a good chunk of it. I knew how to create one and use it, but I didn't know how to pull the information from Torque.. that's where Melv's code came in. This frustum is created with a far clipping plane, thus there will be depth culling which can be a system varaible.
Now, while I can draw bright stars farther out if I so choose, but it would hamper the selection feature. So, I'm going to make like a wireframe s[here feature to signify the outter edge of the view (just so it doesn't look so dumb with the universe dropping off...)
As for mouse selection, it's not hard at all. Just take the mouse coords and compare them to the current screen coord's of the visible stars, which I'm storing with the other star data. Yes, this means the star data will contain world coords and screen coords, but it's the simplest way to do it.
At present, I'm more or less stuck on building the object which can be loaded in a mission then the octree. Doesn't like my object, gonna dupe fxLightDB and alter it as my next attemot. I've already used this octree code in another application, so I'm fairly confident is should work well. The other application was a test of the octree system within the Crystal Space engine (http://www.crystalspace.org in the contest section, it's called PI)
-jtarbox
Associate James Lupiani
Sickhead Games
The big advantages IMHO are speed and clarity. I have them configured to use compiled vertex arrays if available. The framerate hit is negligible. The dots are very precise and small, which is good for far away stars, and I have some extra little transformations and alpha changes in there to give it more variety and fill out the sky a little. Background skybox images can be used for nebulae, and I've recently utilized Melv May's fxSunFlare to make a nice big local star.
Edit: Hmm, guess the markup lite reference is out of date.