Fractal Generation System

[Shark]

As for the orbits, most of them are probably elliptical, is that there are just so many of them, and they are spaced more or less equality that it appears, and is on a hole very circular.

That's good news.

Where it becomes really fun is in planetary rings. The density of those are much greater.

Maybe a mesh should be created for "dust". It is very fine and depletes shields.

[Shark]

I don't know if this would be too much to ask, but could you create a heightfield for me that is based upon the strength of the gravitational fields? Since the heightfield would be 2-dimensional image, it would have to be a cross-section (slice) of the universe.

[richard]

Actually, there are a lot fewer asteroids then I original though. This makes it so in real life the density in the belt is perhaps one object every 1000km or more. Not very dramatic is it.

This has been brought up before. I'd personally have no problems with the asteroid field in VS being far less dense. As I pointed out in another post, I think the current asteroid fields in VS have problems.

OTOH, as you point out planetary rings are more dense. How large do the components of rings get?

[mkruer]

Well "The sizes range from grains of sand to boulders as big as houses (larger than 10 meters across), and they are loosely distributed. The most abundant particles are 10 cm across." Also the rings are only about 200 to 3000m thick.

[richard]

OK, so given that info, the people who'd like to have a more dense field of rocks can still have one if the asteroid fields are made more realistic...

[mkruer]

Well the info that I gave you was for Saturn, and unfortunately that is the only real example we have, and this could be the exception not the rule. However we could speculate a middle ground if you want.

[mkruer]

I don't know if this would be too much to ask, but could you create a heightfield for me that is based upon the strength of the gravitational fields? Since the heightfield would be 2-dimensional image, it would have to be a cross-section (slice) of the universe.

Here is a quick n' dirty version.

[mkruer]

@oligo

I was wondering if you could help me find some more equations for some of the Graphs on the other page. I really haven’t had the time lately to find the general equations myself. You seem to have a much better knack for it then I do.

Also I am updating the NEO and asteroids to include specific data about the asteroids them selves

Mass: (looking for a cure to match this)
75% 1g/cm^3
20% 2.6/cm^3
5% 8.5/cm^3

Rotation: 1-10hrs avg. (Standard deviation curve)
Tilt; 1-180 (Unknown)
Precession Rate: The spin rate of the tilt (unknown)

Anthing else i am missing?

[oligo]

of course, could you point me out which ones ?
Do you need a better moon distribution formula ? I think I can improve the first version I made.

oligo

[Shark]

Here is a quick n' dirty version.

Ooooh. Sweet! I'll take a look at it later. Thanks.

[edit] That's not a heightfield

[mkruer]

of course, could you point me out which ones ?
Do you need a better moon distribution formula ? I think I can improve the first version I made.

oligo

I think all the ones you gave me, i played around with them enough to get them to 95%+ accurecy

Orbiting Moons
Eccentricity; See Chart
Inclination; See Chart
Diameter/Size; See Chart
Orbital Distance; See Chart

Asteroids (2686)
Orbital Distance; See Chart

Comets (41)
Inclination; See Chart
Diameter/Size; Unknown/No Information
Orbital Distance; See Chart

Asteroid Belt (See Chart; est. total mass 3.6E+22 kg current, > 2E+25, when system formed)
Eccentricity; Enough to keep it with the defined area
Inclination; Enough to keep it with the defined area
Diameter/Size; <1000km
Orbital Distance; 2-4AU

[Guest]

I just posted an applet illustrating an algorithm for generating random networks that are compatible with LOD terrain algorithms. I intend to integrate this into the terrapin engine that was mentioned a few posts up. I think these networks could be used for cracks in plates; I was intending to directly use them as ridgelines for mountains, and also rivers. And what the hey, roads. Needs a bit more work for the last two.

It's at http://snork.home.texas.net/jason/river/river.html.

By "compatible with LOD" I mean that you don't have to evaluate the whole mesh, and you always get the same network regardless of what order of expansions you use.

At some point I will GPL all this stuff, it's just a bit embarassing right now to send out into the world.
------
jason

[Shark]

I just posted an applet illustrating an algorithm for generating random networks that are compatible with LOD terrain algorithms. I intend to integrate this into the terrapin engine that was mentioned a few posts up. I think these networks could be used for cracks in plates; I was intending to directly use them as ridgelines for mountains, and also rivers. And what the hey, roads. Needs a bit more work for the last two.

It's at http://snork.home.texas.net/jason/river/river.html.

By "compatible with LOD" I mean that you don't have to evaluate the whole mesh, and you always get the same network regardless of what order of expansions you use.

At some point I will GPL all this stuff, it's just a bit embarassing right now to send out into the world.
------
jason

It's not rendering to the screen. All the controls are there, but the screen stays black.

[Guest]

It's not rendering to the screen. All the controls are there, but the screen stays black.

I haven't seen that failure mode. Does your java work ok otherwise? Also, I
have seen it behave strangely when brought up with the browser sized so that the whole
applet isn't on the page. I have tried it only with fairly recent opera and mozilla on linux.

You can email me at jasonmod@DitchThis_texas.net if you still have trouble.
- jason

[mkruer]

Can I make a recommendation? After you take get the point on the hex grid, create a spline that try to link all the points. This will eliminate all the hard edges and make it more naturalistic.

[mkruer]

Here is a quick n' dirty version.

Ooooh. Sweet! I'll take a look at it later. Thanks.

[edit] That's not a heightfield

[oligo]

of course, could you point me out which ones ?
Do you need a better moon distribution formula ? I think I can improve the first version I made.

oligo

I think all the ones you gave me, i played around with them enough to get them to 95%+ accurecy

Orbiting Moons
...

Some graph won't be easy (impossible?) to create from a math formula esp. moon distance (with gaps) or grade moon inclination...
Why not use hard coded arrays cause you seem to have exported values in a graph app ?
for instance: float f[] = {y1, y2, y3, ... };
Then you could retrieve the value doing linear/bilinear interpolation between the y values (a class could handle these features).
The accuracy would be much better as the resulting value will rely on real data instead of math formula.

oligo

[Shark]

Here is a quick n' dirty version.

Ooooh. Sweet! I'll take a look at it later. Thanks.

[edit] That's not a heightfield

Oh shit!

[Guest]

Can I make a recommendation? After you take get the point on the hex grid, create a spline that try to link all the points. This will eliminate all the hard edges and make it more naturalistic.

Certainly something like that is a good idea; after a certain level of refinement, it will need to stop putting in more twists and turns and start smoothing. In fact, this has to happen "on" the hex grid, just at and below some certain level of detail. And then eventually (at even finer levels) some sort of "river template" with banks, water, sandbars, etc should be applied.

I probably can't use a spline. Iirc splines involve some transformation of ALL the points, but if I want to stay LOD compatible I have to do something at each expansion that is local to the cell being expanded, and only uses the adjacent cells at one-level-coarser, etc. However, I expect I can hack together some LOD smoothing algorithm.

[mkruer]

of course, could you point me out which ones ?
Do you need a better moon distribution formula ? I think I can improve the first version I made.

oligo

I think all the ones you gave me, i played around with them enough to get them to 95%+ accurecy

Orbiting Moons
...

Some graph won't be easy (impossible?) to create from a math formula esp. moon distance (with gaps) or grade moon inclination...
Why not use hard coded arrays cause you seem to have exported values in a graph app ?
for instance: float f[] = {y1, y2, y3, ... };
Then you could retrieve the value doing linear/bilinear interpolation between the y values (a class could handle these features).
The accuracy would be much better as the resulting value will rely on real data instead of math formula.

oligo

I am trying to avoid that as much as much as possible. A cure is much more naturalistic then a plot, and over time plots become extremely evident.

One of the things I have be playing around with is taking multiple formulas and combining them in to a single one. The original graph was really 2 graphs using distance to find the location. The new graphs are all percentages or probability.

For the moons it turns out (if you looked as the second graph) that there is a consistent void region that exist from the moons that are grade vs. retro. On the part that is close to the planet, all the moons follow the rotation, away from the planet, it is the exact opposite. The reason for this is incredibly oblivious once you think about it. Most if not all moons are captured bodies. The moons that are the farthest away are captured Trojan asteroids. Well it turn out that the closer the moon gets, (and for larger planets it will happen) there is additional drag on the moon that is going retro to the rotation. This basically means the those moons have to maintain a minimum distance before the moon gets too close and the drag, make the moon plummet into the planet. For the closer moons, it turns out that because there is less drag, they can cope much better closer into the planet. Then this leave the question why are there not more moons at grade then retro on the outside of that gap. This turns out to be simple as well. The Trojan’s that orbit at the L4 and L5 points are rotation around those points at grade, but just like two wheels when the other takes hold (via gravity in this case) the new path is exactly opposite of the first. So the reason ends up being that 90+% off all the moons are going to start off in the opposite direction. Finally what does this mean in the end? Simple there are 3 curves. One for the grade. Starting off with a high probability close to the planet, the second one, is retro which has a high probability toward the outside and nil close to the plant. And finally the void gap which is the more of less the probability of finding anything there at all.

Hope that all made sence.

[Starchild]

It's not rendering to the screen. All the controls are there, but the screen stays black.

I haven't seen that failure mode. Does your java work ok otherwise? Also, I
have seen it behave strangely when brought up with the browser sized so that the whole
applet isn't on the page. I have tried it only with fairly recent opera and mozilla on linux.

You can email me at jasonmod@DitchThis_texas.net if you still have trouble.
- jason

I think I may know to cause of the problem. I'm guessing you are using swing components?
Any components starting with 'J' are only visible in browsers that have a reasonably recent java version. I belive explorer comes with the rather ancient 1.1 version as default.

I can't see it in explorer(1.1), but I can see it in mozilla(using 1.4 from sun).

[Guest]

It's not rendering to the screen. All the controls are there, but the screen stays black.

I haven't seen that failure mode. Does your java work ok otherwise? Also, I
have seen it behave strangely when brought up with the browser sized so that the whole
applet isn't on the page. I have tried it only with fairly recent opera and mozilla on linux.

You can email me at jasonmod@DitchThis_texas.net if you still have trouble.
- jason

I think I may know to cause of the problem. I'm guessing you are using swing components?
Any components starting with 'J' are only visible in browsers that have a reasonably recent java version. I belive explorer comes with the rather ancient 1.1 version as default.

I can't see it in explorer(1.1), but I can see it in mozilla(using 1.4 from sun).

I'm not using swing components; and if there are swing components in an applet, or anything else (like an arraylist) that doesn't exist in java 1.1 sans swing, the applet will generally fail to start at all; I am not doing any dynamic loading of classes so that would happen before the controls got drawn. I wonder if I am running out of memory; the thing uses quite a bit. If one of yall could mail me the java console output when it fails, I would be much obliged. (I tried it on IE and couldn't get it to fail).

[oligo]

I think all the ones you gave me, i played around with them enough to get them to 95%+ accurecy

Orbiting Moons
Eccentricity; See Chart
Inclination; See Chart
Diameter/Size; See Chart
Orbital Distance; See Chart

Asteroids (2686)
Orbital Distance; See Chart
...

I sent you the formulas by email at mkruer at users.sourceforge.net, did you get it?

oligo

[mkruer]

Uh no. I didn’t even realize that I had that e-mail address. Anyway you can sent it to me via PM though the forums. I have been working on solving the moon issue, and thinking about breaking it up into 2 separate equations.

[mkruer]

Scratch that last message. i did get it. I will review it. Thanks.