ROAM Planet rendering
-
- Goblin
- Posts: 236
- Joined: Tue Feb 26, 2008 5:48 pm
- x 3
Re: ROAM Planet rendering
It's great to hear to fixed your shader problem, and thanks for keeping us updated.
Do you have any plans for displacement effects? I just saw this and, boy, it makes a difference: http://www.outerra.com/procedural/demo2.html
Do you have any plans for displacement effects? I just saw this and, boy, it makes a difference: http://www.outerra.com/procedural/demo2.html
-
- Orc
- Posts: 400
- Joined: Thu Apr 23, 2009 7:23 am
- Location: Australia
- x 19
Re: ROAM Planet rendering
g'day Aguru,
I checked out that site, and the engine looks good, and yes, the displacement algo's make a real difference.
with regards to that, I think I mentioned earlier in the posts that that was the plan, I'm gonna use the mesh that is generated on the CPU as a collision mesh and the low res mesh that the shaders will use as a foundation for the finer detail to be generated by the GPU, just that these guys beat me to it (good on 'em).
I'm still getting my head around these shaders, but as I progress, I realize just how much can be done on the GPU, and opens up a whole lot of possibilities for me.
Those guys are using a base height map data to produce landmasses on their planets, I'm not trying to do that with this routine, I'm trying to achieve a totally procedural planetary engine, with height data as the add on, not the other way around, as I feel it would be more useful this way, especially for a game engine.
Imagine a game artist wants to add in a city to the planet, with my implementation all he does is build the landmass immediately under the city, populate it with whatever he likes, then outputs the mesh data, in the engine all he has to do is give it a latitude and longitude to where it should be placed on the surface of the planet, and it will just blend into the terrain mesh using a weighted priority at the edges where it meets the planetary terrain.
This will enable game designers to only add in hires data where needed, and that will save a ton of storage data, and for the player, they will be able to traverse the city like any other level out there at the moment, and if the player wants to get adventurous, they can leave the city an walk the badlands as such for as long as they like, and the only data needed is the add ons, like rocks and trees an such, with the odd NPC baddie out there to give him grief, and maybe meat some other adventurer out there.
regards
Alex
I checked out that site, and the engine looks good, and yes, the displacement algo's make a real difference.
with regards to that, I think I mentioned earlier in the posts that that was the plan, I'm gonna use the mesh that is generated on the CPU as a collision mesh and the low res mesh that the shaders will use as a foundation for the finer detail to be generated by the GPU, just that these guys beat me to it (good on 'em).
I'm still getting my head around these shaders, but as I progress, I realize just how much can be done on the GPU, and opens up a whole lot of possibilities for me.
Those guys are using a base height map data to produce landmasses on their planets, I'm not trying to do that with this routine, I'm trying to achieve a totally procedural planetary engine, with height data as the add on, not the other way around, as I feel it would be more useful this way, especially for a game engine.
Imagine a game artist wants to add in a city to the planet, with my implementation all he does is build the landmass immediately under the city, populate it with whatever he likes, then outputs the mesh data, in the engine all he has to do is give it a latitude and longitude to where it should be placed on the surface of the planet, and it will just blend into the terrain mesh using a weighted priority at the edges where it meets the planetary terrain.
This will enable game designers to only add in hires data where needed, and that will save a ton of storage data, and for the player, they will be able to traverse the city like any other level out there at the moment, and if the player wants to get adventurous, they can leave the city an walk the badlands as such for as long as they like, and the only data needed is the add ons, like rocks and trees an such, with the odd NPC baddie out there to give him grief, and maybe meat some other adventurer out there.
regards
Alex
-
- Gnoblar
- Posts: 7
- Joined: Tue Feb 23, 2010 3:10 am
Re: ROAM Planet rendering
This looks awesome. Am I right in thinking that there is no source code released yet? Any idea when this might happen?
Thanks.
Simon
Thanks.
Simon
-
- Orc
- Posts: 400
- Joined: Thu Apr 23, 2009 7:23 am
- Location: Australia
- x 19
Re: ROAM Planet rendering
G'day Simon,
You are right, the source hasn't been released. The reason being that it isn't ready for main stream yet, I'm trying to get the terrain handling as user friendly and flexible as I can, so that when someone wants to put something somewhere, it will happen with a minimum of fuss, as well as let them add in shadows (of any type), enable self shadowing, get access to all manner of information embedded in the terrain data (eg... Height, slope, makeup (as in rock, dirt, sand and such), climate/average temperature, river bed, all that kind of stuff) and also allow you to incorporate your own data in there as well, not to mention adding in more traditional terrain data, like DEM's or just plain level geometry.
Allot of this stuff is already working, I'm just adding in allot of the things I need to make the terrain more shadow friendly, and getting the rivers and lakes system to work properly, without blowing out the RAM and GRAM usage all the while keeping the frame rate above 150 fps on my XP box, just an average machine. I put it on my sons laptop, a power house machine, and the thing ran at 350 fps at full res and as smooth as silk on Windows 7 64bit. And on my machine it runs at around 112 fps, still OK, but I'm refining the data structures a little to get optimum power out of the data, all the while keeping the memory footprint under approximately 100 mb, that's including moons and such that are visible from the ground also. OH YEAH, It now has more than one planet.
anyways, I'll keep you informed, but as yet, it really isn't ready for the mainstream, so please be patient
regards
Alex
You are right, the source hasn't been released. The reason being that it isn't ready for main stream yet, I'm trying to get the terrain handling as user friendly and flexible as I can, so that when someone wants to put something somewhere, it will happen with a minimum of fuss, as well as let them add in shadows (of any type), enable self shadowing, get access to all manner of information embedded in the terrain data (eg... Height, slope, makeup (as in rock, dirt, sand and such), climate/average temperature, river bed, all that kind of stuff) and also allow you to incorporate your own data in there as well, not to mention adding in more traditional terrain data, like DEM's or just plain level geometry.
Allot of this stuff is already working, I'm just adding in allot of the things I need to make the terrain more shadow friendly, and getting the rivers and lakes system to work properly, without blowing out the RAM and GRAM usage all the while keeping the frame rate above 150 fps on my XP box, just an average machine. I put it on my sons laptop, a power house machine, and the thing ran at 350 fps at full res and as smooth as silk on Windows 7 64bit. And on my machine it runs at around 112 fps, still OK, but I'm refining the data structures a little to get optimum power out of the data, all the while keeping the memory footprint under approximately 100 mb, that's including moons and such that are visible from the ground also. OH YEAH, It now has more than one planet.
anyways, I'll keep you informed, but as yet, it really isn't ready for the mainstream, so please be patient
regards
Alex
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: ROAM Planet rendering
It's your show, and you call the shots.DavlexDesign wrote:anyways, I'll keep you informed, but as yet, it really isn't ready for the mainstream, so please be patient

/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- Greenskin
- Posts: 121
- Joined: Thu Feb 18, 2010 8:05 am
- x 2
Re: ROAM Planet rendering
As jacmoe said, you call the shots on that. I am personally VERY interested in seeing some of the source code for it myself, so can appreciate the desire of others to prod you on details 
For me, the desire is purely intellectual at this stage. My current project has very limited "open areas", which should be easily handled using the existing OGRE Terrain plugin/component (once we work out the static linking issue). I have a tentative nibble on a future project though that could make use of it but nowhere near the stage where I need to be scheduling code.

For me, the desire is purely intellectual at this stage. My current project has very limited "open areas", which should be easily handled using the existing OGRE Terrain plugin/component (once we work out the static linking issue). I have a tentative nibble on a future project though that could make use of it but nowhere near the stage where I need to be scheduling code.
-
- Orc
- Posts: 400
- Joined: Thu Apr 23, 2009 7:23 am
- Location: Australia
- x 19
Re: ROAM Planet rendering
G'day BTolputt,
Sounds like you're on your way to getting something going also, and this engine will be able to incorporate Steve's Terrain plugin for localized terrain around key areas (if you need it), I am trying to make this thing as flexible as possible.
As for releasing it, the code is nowhere near mainstream, because of the tightness internally, and the many incorporated features that the engine has, I feel to do it justice, the code will need allot more commenting in it, to explain what the hell is going on inside the subroutines, so that someone coming from outside can get a handle on how it works, plus, I think it almost warrants a manual and a structured flow document to explain how it all comes together.
This thing no longer runs serially, it uses parallel processes sort of like job cards that get given priorities as to when or if they are required by some other system a little further down the pipeline, and this system can get quite confusing if you can't understand it.
It would be a real shame to release this thing too soon, and then have people trying to use it, and just shove it in the too hard basket, and then just go hunting some where else for a solution. I've put allot of time and brain bending effort into this thing, and that's the last thing I want to happen.
I really want this thing to do Sinbads' OGRE engine justice, and really make it Next Gen as such, and it's nearly there now.
so as I keep iterating, please be patient.
regards
Alex
Sounds like you're on your way to getting something going also, and this engine will be able to incorporate Steve's Terrain plugin for localized terrain around key areas (if you need it), I am trying to make this thing as flexible as possible.
As for releasing it, the code is nowhere near mainstream, because of the tightness internally, and the many incorporated features that the engine has, I feel to do it justice, the code will need allot more commenting in it, to explain what the hell is going on inside the subroutines, so that someone coming from outside can get a handle on how it works, plus, I think it almost warrants a manual and a structured flow document to explain how it all comes together.
This thing no longer runs serially, it uses parallel processes sort of like job cards that get given priorities as to when or if they are required by some other system a little further down the pipeline, and this system can get quite confusing if you can't understand it.
It would be a real shame to release this thing too soon, and then have people trying to use it, and just shove it in the too hard basket, and then just go hunting some where else for a solution. I've put allot of time and brain bending effort into this thing, and that's the last thing I want to happen.
I really want this thing to do Sinbads' OGRE engine justice, and really make it Next Gen as such, and it's nearly there now.
so as I keep iterating, please be patient.
regards
Alex
-
- Goblin
- Posts: 254
- Joined: Tue Feb 13, 2007 5:33 am
Re: ROAM Planet rendering
Very good news indeed. We understand that good things need time to bake properly, but... could you post some teaser screenshots at least, please?
-
- Gremlin
- Posts: 151
- Joined: Sun Jun 22, 2008 8:29 pm
- Location: Nantes, France
- x 1
Re: ROAM Planet rendering
This reminds me of this article :DavlexDesign wrote:It would be a real shame to release this thing too soon, and then have people trying to use it, and just shove it in the too hard basket, and then just go hunting some where else for a solution. I've put allot of time and brain bending effort into this thing, and that's the last thing I want to happen
http://www.codinghorror.com/blog/2009/1 ... nyway.html
Without agreeing to everything Jeff Atwood is saying (be it in this article or another), maybe you're seeing us too much like ferocious beasts

I'm not really sure releasing your engine earlier will do so much harm to your work.
We're mainly between developpers here, and we are more capable than average non technical users to understand that if it "sucks" at some stage, throwing it away is just stupid.
Last edited by Fulmens on Wed Feb 24, 2010 4:32 pm, edited 1 time in total.
-
- OGRE Retired Team Member
- Posts: 3335
- Joined: Tue Jun 21, 2005 8:26 pm
- Location: Rochester, New York, US
- x 3
Re: ROAM Planet rendering
Release early release often?
If you really want to release this just don't fall into the "not quite ready" trap. Nothing is ever quite ready.
If you really want to release this just don't fall into the "not quite ready" trap. Nothing is ever quite ready.
Game Development, Engine Development, Porting
http://www.darkwindmedia.com
http://www.darkwindmedia.com
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: ROAM Planet rendering
Uhuh - then how about releasing that stuff of yours?Praetor wrote:Release early release often?

Or, is it not quite ready?

In all seriousness, I think that you *can* release something too early.
And I think Alex already explained why.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- OGRE Retired Team Member
- Posts: 3335
- Joined: Tue Jun 21, 2005 8:26 pm
- Location: Rochester, New York, US
- x 3
Re: ROAM Planet rendering
funny you should mention a release...
But seriously it's sometimes a tough decision. Just wanted to make it clear that a "when it's ready" mindset can ensure good quality, but it can also be a mental trap. http://www.youtube.com/watch?v=piVnArp9ZE0
But seriously it's sometimes a tough decision. Just wanted to make it clear that a "when it's ready" mindset can ensure good quality, but it can also be a mental trap. http://www.youtube.com/watch?v=piVnArp9ZE0
Game Development, Engine Development, Porting
http://www.darkwindmedia.com
http://www.darkwindmedia.com
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: ROAM Planet rendering
You lost me there - probably a good thing..Praetor wrote:funny you should mention a release...

In this particular case, I think we can assume that Alex is in control of it, and that it's not turning into a DNFPraetor wrote:But seriously it's sometimes a tough decision. Just wanted to make it clear that a "when it's ready" mindset can ensure good quality, but it can also be a mental trap.

/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- Orc
- Posts: 400
- Joined: Thu Apr 23, 2009 7:23 am
- Location: Australia
- x 19
Re: ROAM Planet rendering
Thanks jacmoe,
You are right, I've committed myself to this project, and I do have it under control, so you don't have to worry about it becoming a DNF (don't know what that stands for)
It's becoming a real heavy brain bender lately, trying to get everything in there and running smoothly all the while keeping the RAM and GRAM usage to a bare minimum (I'm thinking I may have to blow it out to around 150 mb of RAM and say 60 - 70 mb GRAM to get that Vue (e-on Software) Look ( which it can do now), but I'll see what I can do). Not to mention, getting the batching just right as well, because of the dynamic nature of the mesh, I'm currently adjusting the way it sends info to the video card, so that it doesn't hit it as hard, and as frequently, all the while, trying to keep the terrain rubber banding to a bare minimum.
As soon as I get it running again, I'll send up a couple of teaser screen shots.
regards
Alex
You are right, I've committed myself to this project, and I do have it under control, so you don't have to worry about it becoming a DNF (don't know what that stands for)
It's becoming a real heavy brain bender lately, trying to get everything in there and running smoothly all the while keeping the RAM and GRAM usage to a bare minimum (I'm thinking I may have to blow it out to around 150 mb of RAM and say 60 - 70 mb GRAM to get that Vue (e-on Software) Look ( which it can do now), but I'll see what I can do). Not to mention, getting the batching just right as well, because of the dynamic nature of the mesh, I'm currently adjusting the way it sends info to the video card, so that it doesn't hit it as hard, and as frequently, all the while, trying to keep the terrain rubber banding to a bare minimum.
As soon as I get it running again, I'll send up a couple of teaser screen shots.
regards
Alex
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: ROAM Planet rendering
DNF stands for Duke Nukem Forever. 

/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- Greenskin
- Posts: 121
- Joined: Thu Feb 18, 2010 8:05 am
- x 2
Re: ROAM Planet rendering
Perhaps it is simply fate then that Duke Nukem Forever was never finished (and never will be).JustBoo wrote:In racing, as perhaps in life, it's also Did Not Finish.
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: ROAM Planet rendering
Click the link, it's not fate. It's Broussard. 

/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- Greenskin
- Posts: 109
- Joined: Sat Dec 20, 2008 6:26 am
- Location: QLD, Australia
- x 3
Re: ROAM Planet rendering
Business 101
Never answer to anyone else but yourself.
Follow this and don't go the path of Shareholders or being bought out by another company and become the employee... You won't run into these problems. Unless of course, you bite off more than you can chew.
Never answer to anyone else but yourself.
Follow this and don't go the path of Shareholders or being bought out by another company and become the employee... You won't run into these problems. Unless of course, you bite off more than you can chew.
-
- Gnoblar
- Posts: 20
- Joined: Thu Dec 17, 2009 5:27 am
Re: ROAM Planet rendering
So sevearly want to attack this
I havnt even started playing with ogre yet, though been working on other aspects of a game.
got a question for you though, Will this be able to be edited on the fly? I mean.. throw a moon at it, have some nice special effects, then drastically modify the data behind the scenes, and when the dust clears the new shape is rendered? or a smaller scale, small impact craters, mining out chunks of the planet, procedural tectonics, volcanism and so forth?
how static is the planet?
also, were thinking about the most part of planetary data being losely defined and only a few 'hard points' on the planet surface that are relatively static.. so you migth have a mountain range far to the east.. and a single vast city where you are... between you and the city would be a desert... a desert that isnt really defined, just described as desert of x type material.. and visiting it each time the shape and pattern of dunes and vegetation would change.
I suppose it could be done at the very least, as the planet engine does the bedrock, while there is a second overlay over the section that is described as desert, something like a subunit

I havnt even started playing with ogre yet, though been working on other aspects of a game.
got a question for you though, Will this be able to be edited on the fly? I mean.. throw a moon at it, have some nice special effects, then drastically modify the data behind the scenes, and when the dust clears the new shape is rendered? or a smaller scale, small impact craters, mining out chunks of the planet, procedural tectonics, volcanism and so forth?
how static is the planet?
also, were thinking about the most part of planetary data being losely defined and only a few 'hard points' on the planet surface that are relatively static.. so you migth have a mountain range far to the east.. and a single vast city where you are... between you and the city would be a desert... a desert that isnt really defined, just described as desert of x type material.. and visiting it each time the shape and pattern of dunes and vegetation would change.
I suppose it could be done at the very least, as the planet engine does the bedrock, while there is a second overlay over the section that is described as desert, something like a subunit
-
- Greenskin
- Posts: 109
- Joined: Sat Dec 20, 2008 6:26 am
- Location: QLD, Australia
- x 3
Re: ROAM Planet rendering
The planets will not be static... Even the moons and suns wont be static.
You could blow off half your moon and see the change as it happens on the surface of a planet.
We are looking at being able to build on partially/mostly destroyed planetoids.
We haven't decided how we are going to handle things like volcanoes yet, but the engine can handle a dynamic rise in terrain.
If you have ever seen the Volcano Miracle in Black and White 2, that is what I am talking about.
We are trying to make this thing as dynamic as we can... We want to be able to throw anything you can think of it at, and have it respond the way it should.
You could blow off half your moon and see the change as it happens on the surface of a planet.
We are looking at being able to build on partially/mostly destroyed planetoids.
We haven't decided how we are going to handle things like volcanoes yet, but the engine can handle a dynamic rise in terrain.
If you have ever seen the Volcano Miracle in Black and White 2, that is what I am talking about.
We are trying to make this thing as dynamic as we can... We want to be able to throw anything you can think of it at, and have it respond the way it should.
-
- Orc
- Posts: 400
- Joined: Thu Apr 23, 2009 7:23 am
- Location: Australia
- x 19
Re: ROAM Planet rendering
G'day guys,
With regards to the modding of the terrain, all those things should be possible, like Suvaka said, ...
What I mean about breaking up the terrain into smaller and smaller blocks, is not like the normal stuff of going down to just a certain res for pages and that's as far as it goes, what I'm talking about, is having the terrain engine do that for starters, but if the engine needs to, it will go past the desired res we stipulate on creation, and page down even further to allow such effects as creating debris and things if there is a large impact on the planets surface, the beauty is, that the pages can be thrown out and can be manipulated like entities in their own right, and they will have underside data if exposed like that. The reason for this effect is so that we can split the planet in half if we want, and it will crack and shatter like expected, exposing the cores and mantle and stuff like that, and if that happens, we want to still be able to fly close to and through the planets pieces.(that's the plan anyway)
Another thing, this engine doesn't only handle spherical terrains either, if you want it flat like conventional terrains, it can do that too.
I think that once the paging system is finished, It should be quite versatile, and be able to be used for any number of purposes other than terrain, just have to see how it handles the ram requirements, I'm keeping the resources it requires down to a bare minimum, so If I can get it to run in real time on my personal machine, it should run great on most other machines too.
At the moment it runs at around 100 - 200 fps on my machine, the slower times are when I'm really pumping the resolution of the mesh, but now that the stable release of 1.7 is out, I'll have a play with the worker thread a little more and see what I can do.
I'm also getting allot more comfortable with the shader coding now too, understanding the limitations and also the possibilities that the GPUs have. it's been interesting, it's more or less just a really suped up version of the old "Blitter chip" in the Amiga computer, I remember coding it years ago (in assembler) and that was fun too. (OOPS!, I'm showing my age)
Anyway, it shouldn't be too long and I'll upload some screens for you guys to have a look at
regards
Alex
With regards to the modding of the terrain, all those things should be possible, like Suvaka said, ...
and that is one of the reasons for the paging update that I'm working on now, this new system will allow me to really break up the terrain into smaller and smaller blocks on the fly, also dealing with pre-built height map terrain data as well (haven't looked at pre-built terrain mesh data yet, but should be possible).We are trying to make this thing as dynamic as we can
What I mean about breaking up the terrain into smaller and smaller blocks, is not like the normal stuff of going down to just a certain res for pages and that's as far as it goes, what I'm talking about, is having the terrain engine do that for starters, but if the engine needs to, it will go past the desired res we stipulate on creation, and page down even further to allow such effects as creating debris and things if there is a large impact on the planets surface, the beauty is, that the pages can be thrown out and can be manipulated like entities in their own right, and they will have underside data if exposed like that. The reason for this effect is so that we can split the planet in half if we want, and it will crack and shatter like expected, exposing the cores and mantle and stuff like that, and if that happens, we want to still be able to fly close to and through the planets pieces.(that's the plan anyway)
Another thing, this engine doesn't only handle spherical terrains either, if you want it flat like conventional terrains, it can do that too.
I think that once the paging system is finished, It should be quite versatile, and be able to be used for any number of purposes other than terrain, just have to see how it handles the ram requirements, I'm keeping the resources it requires down to a bare minimum, so If I can get it to run in real time on my personal machine, it should run great on most other machines too.
At the moment it runs at around 100 - 200 fps on my machine, the slower times are when I'm really pumping the resolution of the mesh, but now that the stable release of 1.7 is out, I'll have a play with the worker thread a little more and see what I can do.
I'm also getting allot more comfortable with the shader coding now too, understanding the limitations and also the possibilities that the GPUs have. it's been interesting, it's more or less just a really suped up version of the old "Blitter chip" in the Amiga computer, I remember coding it years ago (in assembler) and that was fun too. (OOPS!, I'm showing my age)
Anyway, it shouldn't be too long and I'll upload some screens for you guys to have a look at
regards
Alex
-
- Gnoblar
- Posts: 20
- Joined: Thu Dec 17, 2009 5:27 am
Re: ROAM Planet rendering
Very interesting. I do hope you release soon so I can begin playing with it, even an alpha version without full features would allow us to build around it and just leave placeholder functions waiting for other features.
Part of what were planning is to have dozens of star systems, each containing numerous planets... and each planet able to be fully utilized and colonized, even potentially destroyed. Data size wont matter as much, weve got terrabytes to throw at it, and with a client/server layout, only need to send data pertaining to what the client needs.
we were intending to write our own planetary engine, but seeing what you guys were doing here made us rethink.
When you do release it, what license will it be under?
also, how modular is the code? I know you wrote in some terrain functions to sprinkle trees about, is that just an example placeholder that can be easily cut out or replaced?
same question for the sky.
Part of what were planning is to have dozens of star systems, each containing numerous planets... and each planet able to be fully utilized and colonized, even potentially destroyed. Data size wont matter as much, weve got terrabytes to throw at it, and with a client/server layout, only need to send data pertaining to what the client needs.
we were intending to write our own planetary engine, but seeing what you guys were doing here made us rethink.
When you do release it, what license will it be under?
also, how modular is the code? I know you wrote in some terrain functions to sprinkle trees about, is that just an example placeholder that can be easily cut out or replaced?
same question for the sky.
-
- Gnoblar
- Posts: 20
- Joined: Thu Dec 17, 2009 5:27 am
Re: ROAM Planet rendering
really, just a comment about what license you are going to release it under would be greatly helpful... Please? 

-
- Greenskin
- Posts: 109
- Joined: Sat Dec 20, 2008 6:26 am
- Location: QLD, Australia
- x 3
Re: ROAM Planet rendering
We are trying to make the engine as modular as possible so you can just drop in the new code and have it work. We are doing it this way so that we can have a two fold effect;
#1 - Addition of functions through patching
#2 - Unloading certain modules for people on lower end systems.
- Not only will this increase their framerate by removing said system, but it will also improve memory performance due to not having to run this module at all.
As it stands at this moment, the engine will be setup to randomly create a single galaxy. Tho with a 'module'
it will be expandable to how ever many galaxies you want.
In regards to the licence, we haven't decided which way we are going to go yet.
We wish to release a free version of the engine - maybe just missing a few modules and restricted as non profit.
However we are also looking at a licence structure so that people with a little bit of money behind them, can take full commercial advantage of the engine.
It is still up in the air at the moment... and I will give you an example as to why;
We are looking at integrated some middle-ware in our engine, being Speedtree and Euphoria.
At the moment, these are ideas we are tossing around. So if we go with some middle-ware, then there will definitely need to be some kind of cost and licencing structure.
As we can't give away others products.
That being said, these would be modular additions and could be ... excluded
But stay tuned... We have something HUGE we wish to announce shortly, that I am sure everyone will like
#1 - Addition of functions through patching
#2 - Unloading certain modules for people on lower end systems.
- Not only will this increase their framerate by removing said system, but it will also improve memory performance due to not having to run this module at all.
As it stands at this moment, the engine will be setup to randomly create a single galaxy. Tho with a 'module'

In regards to the licence, we haven't decided which way we are going to go yet.
We wish to release a free version of the engine - maybe just missing a few modules and restricted as non profit.
However we are also looking at a licence structure so that people with a little bit of money behind them, can take full commercial advantage of the engine.
It is still up in the air at the moment... and I will give you an example as to why;
We are looking at integrated some middle-ware in our engine, being Speedtree and Euphoria.
At the moment, these are ideas we are tossing around. So if we go with some middle-ware, then there will definitely need to be some kind of cost and licencing structure.
As we can't give away others products.
That being said, these would be modular additions and could be ... excluded

But stay tuned... We have something HUGE we wish to announce shortly, that I am sure everyone will like

-
- Gnoblar
- Posts: 20
- Joined: Thu Dec 17, 2009 5:27 am
Re: ROAM Planet rendering
darn, was hoping for something along the lines of BSD or Zlib.