G33X Nexus Entertainment > Precursors

RE: Models, screenshots, etc... in Developers' Discussion

(1/3) > >>

Recon:
Hi,
  Was reading the post http://forums.g33xnexus.com/index.php/topic,639.0.html in the developer discussion forum and though I should let you know what I am up to. I am still very green using C++ and wanted to do something that I found both interesting and useful that could help Precursors.

  Having read the forums and the development WiKi I thought that making a procedural solor system generator would be a good goal as it's not scheduled anywhere and seem a relativity simple piece of coding. Now I cant guaranty I will manage to make this or if it will be any good but I going to give it a try anyway. If I get to a stage where I feel it might be useful I will let you know.

  So, on to some details. I did a few test first just trying to mock up a solar system and immediately had problems with scale. I found that a lot of things stopped working as expected when the position of a mesh was greater than 100,000 from the 0,0,0 position, both lighting and collision detection seem to stop working. ( example world file at
http://www.uploading.com/files/Z38R0FY5/world.zip.html ).

  This world file is quite simple, has 2 camera positions , one near 0,0,0 and one near 100000,0,0 . and a couple of meshes, start walktest at the 0,0,0 position and it works , at the other position nothing is visible and you fall through meshes. So some method of getting around this will be required and I have not thought of one yet.

  So, I decided to continue anyway as generating a solar system to a smaller scale is still useful. Plan to create a class that will generate suns/planest/moons ect using a seed for each solar system and a simple rule base ( something like http://www.geocities.com/TimesSquare/2691/formula.txt ). Plan to shameless use the textures from Celestia for graphics and give each object a orbit and other information. I think that doing all this client side rather that server side is the best approach and using server system time to keep everything synchronised for different clients. (ie when a client logs onto a server, the server gives the client the current server system time, the client then used this to calculate all positions.)

  It's slow going but my C++ is improving the more I use it. And if I can manage to generate a simple solar system with orbits and graphics in Crystal Space I feel I will have managed to achieve something useful.

Regards

whitelynx:
Hard to believe none of us have replied to this post yet... we've been talking about it a lot. :P

It would be great to see you working on a solar system generator, since that's one of the big parts missing from a playability standpoint right now.

As far as scale, that is an inherent problem with Crystal Space. It uses the C++ 'float' type for coordinates, which becomes extremely inaccurate past a certain point. (at something a good bit less than 1000000000, you lose all decimal places and have to deal with integer precision or worse) There are two ways to solve this in CS, each of which has some pros and some cons.

The first way involves splitting the space up into sectors. This works fine on a small scale, but sectors are a technique that is generally more geared toward "indoor" scenes. Basically, you'd have a cube (the current sector) with 6 faces, each of which would be a "portal" to another sector. The reason that this fixes the float issue is that each sector would be based around the origin (0,0,0) and each portal would "warp" back to the other side of the next sector so that you never get further away from the origin than the size of a sector.

The problem with the first solution is that we have to split up space into a large number of sectors, and it gets rather difficult to track what is in which sector. Also, either we have to have a huge amount of separate sectors (so the size is relatively small) or else we'll still run into some jitter near the edges of a sector.

The second solution is to put the player's ship (or character, or whatever) at the origin and translate the rest of the world to be correctly positioned around it. This is a great solution and lends itself well to deep space scenes, because once something is far enough away to cause jitter, the jitter will be small enough and far enough away that you won't notice it.

The problem with this solution is physics. ODE (and the CS physics system in general) tries to move each object around... somehow we have to then translate everything into ship-space coordinates for the renderer. It would be good to do some tests to see how well this method works with physics and whether we can adapt it to work on a large scale. If we can get past the problems with physics integration, this may well be our best solution.

As far as your ideas on seed-based system generation, that looks pretty promising! I'm not sure about using the stuff from Celestia (we'll have to check their license before you commit any of that to the repository) I have some mixed feelings as far as doing the calculations client-side. I think they should definitely be done on the client to improve speed and response, but the server needs to send updates to the clients every once in a while, and even more often if the given object goes outside of its "predicted" path for some reason. (like being rammed by a large ship or something) Keep in mind that regardless of how much of the calculation is done on the client, the server will need to have the final say on anything that affects actual gameplay.

I'd like to set up an account for you on our subversion repository so that you can commit your code there and we can help you out with it. We'll give you a sandbox directory in the repository, and I'll contact you over PM on the forums to get your login information.

Thanks for working on this! It's encouraging to see some other people getting interested in coding for Precursors.

contingencyplan:

--- Quote from: whitelynx on October 16, 2006, 08:50:11 pm ---Hard to believe none of us have replied to this post yet... we've been talking about it a lot. :P

--- End quote ---

Well, I was mainly gonna have us talk about it with him directly before doing anything, but posting first works too :P


--- Quote ---It would be great to see you working on a solar system generator, since that's one of the big parts missing from a playability standpoint right now.

As far as scale, that is an inherent problem with Crystal Space. It uses the C++ 'float' type for coordinates, which becomes extremely inaccurate past a certain point. (at something a good bit less than 1000000000, you lose all decimal places and have to deal with integer precision or worse) There are two ways to solve this in CS, each of which has some pros and some cons.

--- End quote ---

First off, is there no way we can just create a new coordinates class that does doubles (maybe long doubles) instead of floats? Would doing this fix our problem?


--- Quote ---The first way involves splitting the space up into sectors. This works fine on a small scale, but sectors are a technique that is generally more geared toward "indoor" scenes. Basically, you'd have a cube (the current sector) with 6 faces, each of which would be a "portal" to another sector. The reason that this fixes the float issue is that each sector would be based around the origin (0,0,0) and each portal would "warp" back to the other side of the next sector so that you never get further away from the origin than the size of a sector.

The problem with the first solution is that we have to split up space into a large number of sectors, and it gets rather difficult to track what is in which sector. Also, either we have to have a huge amount of separate sectors (so the size is relatively small) or else we'll still run into some jitter near the edges of a sector.

--- End quote ---

Another problem with sectors is having to transition the origin seamlessly. Loading zones are anathema to this game - we *will not* have them (I'm sure that morgul and whitelynx already decided this, but I'm making it emphatic, if not official :D). This in turn means that things can happen on the edges of sectors (space battles and dogfights, for example). These, in turn, likely will go between the sector edges frequently, causing the coordinates to have to be recalculated a BUNCH of times. Inefficient.


--- Quote ---The second solution is to put the player's ship (or character, or whatever) at the origin and translate the rest of the world to be correctly positioned around it. This is a great solution and lends itself well to deep space scenes, because once something is far enough away to cause jitter, the jitter will be small enough and far enough away that you won't notice it.

The problem with this solution is physics. ODE (and the CS physics system in general) tries to move each object around... somehow we have to then translate everything into ship-space coordinates for the renderer. It would be good to do some tests to see how well this method works with physics and whether we can adapt it to work on a large scale. If we can get past the problems with physics integration, this may well be our best solution.

--- End quote ---

Sounds like this would still require an absolute coordinate system, rather than having everything relative to a moving object. Could you elaborate more on this, probably in another thread?


--- Quote ---As far as your ideas on seed-based system generation, that looks pretty promising! I'm not sure about using the stuff from Celestia (we'll have to check their license before you commit any of that to the repository) I have some mixed feelings as far as doing the calculations client-side. I think they should definitely be done on the client to improve speed and response, but the server needs to send updates to the clients every once in a while, and even more often if the given object goes outside of its "predicted" path for some reason. (like being rammed by a large ship or something) Keep in mind that regardless of how much of the calculation is done on the client, the server will need to have the final say on anything that affects actual gameplay.

I'd like to set up an account for you on our subversion repository so that you can commit your code there and we can help you out with it. We'll give you a sandbox directory in the repository, and I'll contact you over PM on the forums to get your login information.

Thanks for working on this! It's encouraging to see some other people getting interested in coding for Precursors.

--- End quote ---

Back to the main point of the post: I heartily agree with whitelynx's last statement. As time goes on, I'm looking forward to working with more than just 2 people (mainly one, since morgul is more a manager than a codester). Like I've said in other posts, I have mad C++ skillz, so *please* contact me directly or via the forums with any programming questions you have. I'll also check in on your little playground area in the repository to see how / what you're up to, and make suggestions as I'm able (if that's alright with you, of course).

Also, we've discussed this, so I may as well make it official: if you can succeed at this, or at least demonstrate a significant effort, then we'll be more than happy to make you a full dev on the team. No, mad C++ skillz are not a "must-have" - we'll teach you what you need to know.

Morgul:
How about a type that can contain an arbitrary number of digits? How about one with an optimised implementation? I happen to know where to get one.

A few years ago, I helped a friend write an RBI class, "Really Big Integer". We needed it for cryptographics purposes.. even long is MUCH to small for a really secure crypto system. He's been tweaking it over the years; Yes, it is only an integer, but it's an integer of theoretically infinite length. I'm sure we could easily represent 10^300th. Now, consider, the galaxy is only 9.4605284 x 10^29 nanometers, so I think we'd be fine without floats. We'd have to do a custom thing for CS, but I think they might go for it.

Oh, I can also say that our implementation is actioly about 2x as fast as python's interpreter's implementation. (My firend looked up how they do arbitrary length ints in python.. they use our method, but it' a bit inefficient.)

I think this is a computer science problem waiting for a computer scientist to answer. :-p

contingencyplan:
Heh - Dr. Desrosiers had us to a similar project, HugeInt, to teach us operator overloading. I'm sure, especially since your friend has been working on it for a while now, that y'all's is a much better system overall. I'm very interested to see this.

The main question is whether we want to represent everything in nanometers (would require a very large number to do anything significant), or treat it as a fixed point (like .NET's System.Decimal type). Personally, I'd like the latter better, so we aren't having to deal in such large numbers (both conceptually and realistically). Talk to your friend and see how easily one could convert his implementation to also do fixed point arithmetic, if you could.

How soon can we get a hold of the library to start looking through it?

Navigation

[0] Message Index

[#] Next page