C2C - Space Terrain

Oh I just realized something! Now I know why the terrain is transparent! When units or terrain features (such as planets) sit on the terrain you have to see the bottom side of them. If it were like an ocean with a surface then you would cut off the bottom part of the units or terrain features (everything underwater).

I guess our space will just have to be black with no stars. :( because if we add the background stars then they will appear on planet terrains and if we put a star texture on the terrain then it will cut off things. *grumble* And moving every feature, and unit up in the Z axis is too hard to do plus it might ruin their animations.

Unless someone has a better idea we will just have to stick with no background stars.
 
A wandering beaver discovers geodes on the moon and quantonium crystals in the asteroid belt.

May need to redo the space terrain since the asteroids don't seem to be sitting in it correctly.
 

Attachments

  • geodes.jpg
    geodes.jpg
    39.6 KB · Views: 212
Redid the space terrain (old art define is still there Koshling, so if this one does not work with viewports I can create a terrain_none for you).

Image 1 - Asteroids and Radiation Cloud working. Black Hole - is this to big Hydro?

Image 2 - Solar System, the orbits move.
 

Attachments

  • space1.jpg
    space1.jpg
    80.4 KB · Views: 195
  • space2.jpg
    space2.jpg
    28.1 KB · Views: 233
@Dancing Hoskuld

1. Looks fine. They were pretty big in FF and other space mods. I think the supernova is around the same size too. The asteroids look good! :goodjob:

2. Hmm. Any planets in the solar system? Do you know how it works? Normally they have a random star in the middle and then random planets around the star.
 
Final Frontier updates the star systems every frame via the Update event's onUpdate event handler. It boils down to doing the stuff in the updateDisplay function in CvSolarSystem.py.

This function resets the plot's feature, then adds the various models to the solar system feature's model (it has a bunch of nodes to add things to it via the feature's "dummy" functions, like addFeatureDummyModel and setFeatureDummyTexture). The nodes are defined in the feature's entry in the CIV4ArtDefines_Feature.xml which maps names to use in the Python to names of dummy nodes in the .nif file and also maps names of things that can be put into the nodes to .nif files for them

The list of things this function does is something like this:

set the orbit dash lines to be invisible

add the correct star type model

add buildings that appear in orbits (there are separate slots for these from the planet slots)

add an astral gate model if needed (picks which one based on number of pieces completed)

then for each planet: set orbit dashed lines for its orbit to be visible, add each planet using the correct type and size and also add atmospheric effect for some types, clouds for the earth-like type, and rings and moon if needed, add population lights effect, add buildings that show (mag-lev network and commercial satellites), and finally the flashing green selection indicator if the planet is selected.

All every screen update, and occasionally between since the update function is called directly at times when something happens that should have a visible effect. I have to assume doing all this in Python every frame has an impact on the frame rate, but it is obviously not too bad.
 
@God-Emperor:

How much of an effect does that have on performance? Python is slow as heck, and calling it every frame can't be good for framerate or turn times.
 
Not true, Python is not in itself slow. People write slow C++ code too. Just ask Koshling.

Yes, that is indeed true. However, I have always read that with Civ it is usually faster to use C++ than Python, and doing an update every frame sounds like a performance hog. If it isn't though, that would be great.
 
Yes, that is indeed true. However, I have always read that with Civ it is usually faster to use C++ than Python, and doing an update every frame sounds like a performance hog. If it isn't though, that would be great.

Both true.

In general, if the main functionality is in the code we're talking about, well written C++ should be about 50-100 times faster than well written Python. However, in THIS case it may well be that the main time consumers are in the graphical redisplay, which is an engine bottleneck, so if that were the dominant factor it wouldn't make much difference. Without analysis it's not really possible to say for this specific case. Moving it to C++ could be anywhere from a negligible speedup to a dramatic one.
 
Rats! The new space terrain breaks viewports.

@Koshling i will create a TERRAIN_NONE to replace the TERRAIN_SPACE you are currently using in viewports. In fact i will define both as the same thing for now then update to the new space terrain when you have converted. Watch the SVN discussion for when I have done it. Thanks.
 
View Ports used TERRAIN_SPACE to keep hidden the plots you have not yet explored. The current one on teh SVN works fine but the new ones from Final Frontier don't (because they are "under" the land terrain) therefor you get the 10 second view of all the lands you have not explored.

This is not a big problem, Koshling wanted a TERRAIN_NONE anyway, he just used TERRAIN_SPACE as a substitute. I will copy the current TERRAIN_SPACE to TERRAIN_NONE then when he has updated I will put in the new space terrains.

Of course this all assumes I can get C2C to work on my machine so that I can test it before releasing it. So far I have not been able to play more than 3 turns and I can't load saves. This is why none of the work I had done on space and martian terrain has been added yet.
 
@Dancing Hoskuld

Martian Barren
Graphic: Mars-Soil from MN
Food: 0
Production: 0
Commerce: 0
Movement: 0
Defense: 0%
Freshwater: No
Health: 0
Improvements: +25% Time to Build
Cities: Normal
Terrain Damage: Yes

I noticed a problem with the Martian Barren Terrain. It currently gives :food: but it should not give :food: (or anything). Just like the Earth Barren terrain gives nothing, hence the name "Barren".

EDIT: Also all Martian terrain needs to give terrain damage.
 
They are all merged into the core terrain XML ie Assets/XML/Terrain/Civ4TefrrainInfos.XML if you want to change them. Today is going to be a RL day, 6 years since dad died, so I wont get to it until tomorrow.
 
Back
Top Bottom