Lightwave scene file for geography explained

I will now explain what I've learned so far about the lightwave scene file for geography.

Many, many thanks to Shane for getting me started

First a little background. The space environment in EoC is organized and controlled by an abstract term called "geography". Through geography, EoC sets up things like; what you see in the distant background outside your ship, what color light a given star throws off, what planets exist and where they're positioned, etc. Pretty much everything related to the environment. Geography consists of several files, all of a different type. Most of these files are located in the geog directory of the resource file.

Here we're going to talk about the Lightwave setup scenes for geography. These setup scene files are each associated with a particular star system and have the same name as that system with a .lws extension. These files can be opened and edited in notepad if you don't have Lightwave and contain information to control such things as:

• The overall lighting within the system, by controlling the color and intensity of the light coming from the system's star (but not the color or appearance of the star itself), as well as the color and intensity of the ambient light in the system
• The number and color of the tiny pinpoint stars visible in the background
• The appearance of the background nebula seen far off in the distance
• The color, brightness, position and number of the distant large stars seen in the background (other stars you can usually travel to)
• Misc lightwave information not related to EoC

These files work together with a system's .map file to provide the look of the system. The .map files generally contain information on the position and composition of all the celestial bodies within a section of space (such as a star system with planets, moons and asteroids), and can themselves be custom created using GrandpaTrout's excellent geogSDK. You can even associate a custom .lws scene file with a custom .map file by simply giving them the same name.

The .lws scene files provide the above information in coordination with what the various other geography files contribute. For instance; if the .map file says that this system contains a blueish star, then the .lws scene file provides a blueish light to illuminate the scene. If the clusters.ini file says that this system is located between star system A and star system C on the star map, then the .lws file will display a small lens flare of the right color to represent star system A on one side of the system and another lens flare to represent star system B on the other side of the system.

But before we do anything I want to clear up some potential confusion. There's been a lot of talk lately about the game's space environment and one term that's been used a little too interchangeably is the word nebula. When I use the word nebula I mean the fog that blocks your view of distant objects like other ships or stations (such as around Lucretia's Base). But when I use the term "background nebula" I mean the distant nebula that make up part of the background space scene. These are two distinctly different entities and I don't want to confuse anyone because I wasn't clear about it. The .lws files control background nebula. The .map files and/or Pog control regular fog nebula.

For the purposes of this tutorial, I'm going to assume that you don't have Lightwave and will be editing these files manually in notepad. So. . .

I would also like to give you a little information about Lightwave to make things easier to understand. First; nulls. Nulls are a device used by lightwave to represent the position, rotation and scale of a point in space. Nulls are invisible except within Lightwave itself, and within Lightwave they function as normal objects with regards to animation, orientation and parenting. Which brings me to the next thing; parenting. In Lightwave, parenting is used to link objects together for the purpose of organization and grouping. The term comes from the parent-child relationship between the linked objects. When one object is parented to another object, it (strangely enough) becomes that objects child. The idea behind this is that when the parent is positioned, rotated and scaled, all of its children are positioned, rotated and scaled with it. Nulls and parenting work very well with each other to create groups for organization.

Ready to start?

We'll use the hoffers_wake.lws as our example. Ok, let's go through it one section at a time and see what we've got:

This is lightwave proprietary info, it defines what the file is and sets up the animation parameters. As a modder, leave it alone, it has nothing to do with EoC and there's no need to screw with it.

Ok, here's our first bit of meaningful info. The first line is the only one you need to pay attention to in this section for modding. It tells lightwave to add a null object to the scene. This null object will represent the center location of our group of pinpoint type background stars. The way that lightwave communicates gamecode information to flux is through the use of special object names. So the info after AddNullObject is actually the null's name, but it also tells flux how to use the object in the game. The numbers for bright and dim star count affect how many of those tiny pinpoint stars show up in the map. So, in our example there will be 2000 bright stars and 100000 dim stars. This means the entire map, not just what's in your view. The tint numbers affect the color of those pinpoint stars. They represent the RGB colors, but in an unusual way. Instead of each color having 255 values, each color is represented by a number in a range from 0.0 to 1.0. This means if you want pure red stars you tint them 1.0, 0.0, 0.0, since red is represented by the first number. Green is the middle number and blue the last. I made one system that had green background nebula and red stars, I called it the Christmas system, lol. The other parameters don't have a use for modding in this section, so leave them be.

Here we're defining the sky dome, or sphere, since it's space. The first line in this section adds a null to represent the location of our object. And it's name tells flux what to use this null for (sky sphere model), and points to an avatar model file in the models directory. So the name of this null actually contains both instructions for flux and a url this time. What this model should be is an inverted sphere mapped with the numbered image files of background nebula in space (I say "should be" because this type of setup is very commonly used in game design for space sims, and the setup looks right). The url specifies a .pso avatar model in this directory, by changing the avatar name from one model to another you change the space nebula background in the game(like from hoffers_wake_nebula to Osprey). If you're particularly ambitious you might even try making your own background nebula pics, slicing them into 6 sections, saving them as .iff and replacing the images for the models in resources/models/ (this is where the background nebula avatars are stored). Or, if you're really ambitious, you could even make an entirely new and different type of background environment (like underwater). Again, the other parameters of this section are LW only, and of no use to modders.

This section only has meaning to those who are making their own maps. The first line adds a null object and specifies that this null will ( I believe) represent the physical location in space (within the 3D scene) of our system center (defined in our .map file). It has been speculated by mdvalley that this null actually represents the position of the player camera within the scene. This is quite posiible. In either case, your geog .lws scene file must have this entry. It is the base null that all other nulls are parented to. The other parameters of minor interest to us in this section are on line 6, these are the position, rotation and scale of the object (or null in this case). Here's how they work (Note:These measurements are in meters and degrees):

-1695 = X position in 3D space
0 = Y position
-145 = Z position
0 = X rotation
0 = Y rotation
180 = Z rotation
1 = X scale
1 = Y scale
1 = Z scale
These parameters work the same way in all the other sections, so I won't mention them again. It is important to note that nulls are only representations of points in space. As such, they are invisible, and scaling will have no visible effect on them. However, anything parented to them will be affected by their position, rotation and scale values.

This null is the root object that all the distant stars represented by lightwave lights are parented to, presumably so that only the root needs to be rotated for adjustment (all the stars will rotate properly with it). Lightwave scenes frequently use a root object for organization.

This section defines the ambient light color and intensity for lightwave only! It is not used by EoC. The ambient light color and level in the game is controlled by another light I will discuss shortly. So don't waste your time trying to change it.

This time line 1 tells lightwave to add a light to the scene and name it <star>. There are only 3 ways to get Lightwave lights to give off light in EoC, name the lights either <star>, <fill> or <glow>. This light represents the color of the light coming from the system star. It does not represent the color of the system star. The color of the star itself is set in the .map file, which I will explain at the end. So it's possible to have the star appear one color but light the scene with a different color. Obviously the important lines here are 10 and 11, light color and intensity. Light color is in standard RGB format and intensity is in lightwave units of brightness, with 1.0 being 100% intensity. Lightwave light intensities can be set from negative values (creating darkness) to the thousands, yes thousands! Only of minor interest is line 12, light type, in this case 0 which indicates a distant type light. A distant type light casts all of it's light rays in a parallel direction, simulating a giant light source; such as the sun. I don't know yet if changing the shadow type will affect the game shadows, but it's pretty unlikely. It is important to note that the flare that can be seen around the star in-game is not a lens flare from this light. It is a seperate sprite that uses it's own grayscale texture. It is not currently known how this sprite gets it's information for coloring the texture.

Just for fun, the Light Type numbers are as follows:
0 - Distant Light (starlight)
1 - Point Light
2 - Spot Light
3 - Linear Light
4 - Area Light

Another light object. This light is the light that controls ambient lighting in the game. This light is very important for dramatic effect, it affects how the shadow side of objects in the game look. In this case light color isn't as important as light intensity. But crank it up to 1.0 anf there would be no shadow side. Everything would be evenly lit from all directions (extremely unrealistic and probably unpleasant). Personally, I think the ambient light in the game is already way to high, so I set the intensity to about 0.050000 and changed the color to white (RGB 255 255 255) for a more realistic space environment. But since in reality there wouldn't be any ambient light in space choose whatever color suits your fancy, or turn it down to zero. This light type is also 0 (distant).

It is important to remember that only lights named <star>, <fill> or glow will actually give off light in the scene. If a light uses any other name, it can only be used to display a lens flare effect. It will not give off any light! No matter what the intensity setting is. It will only display a lens flare effect, as demonstrated by the next light in the list.

Ahhh, now this is interesting. The next nine sections all do exactly the same thing. They add colored lens flares to the scene which represent other distant stars that you can see from your current star system. But that isn't why I say it's interesting. It's interesting because as you may have noticed, this section just added a distant star to be visible from hoffer's wake, that's called HoffersWake! Remember, we're inside the Hoffer's Wake system now, and this light does not represent our central system star. It represents a visible distant star that we can see from hoffer's wake. None of the other system scene files do this repetition of names so I suspect that the only reason a distant Hoffer's Wake star is included inside the Hoffer's Wake system is because of an oversight by the creator of the file, but I could be wrong. A minor mistake at worst, since some people don't even notice these stars in the game.

Anyway, some new parameters included in this section are for the addition of lens flares. Lens flares are what make a light object visible. Normally in 3D scenery a light object just emits light without a visible source (unlike reality). In order to make a light visible in a 3D world an effect called a lens flare must be added. These lens flares provide the viewer with all the effects normally associated with looking at a light (rays, corona, etc). These parameters start on line 14, and mean the following:

LensFlare 1 = This light uses a lens flare. 0 for none.

FlareIntensity 0.008000 = How bright or large the flare appears.

FlareDissolve 0.000000 = Unknown. This is a normal LW lensflare setting, but I've never seen it used for EoC and I don't know what it does. If anyone does know, please let me know.

LensFlareFade 4 = How the flare should fade. The numbers are:
4 - Fade Off Screen
8 - Fade Behind Objects
16 - Fade In Fog
2 - Fade With Distance
You can use any combination of these to achieve the desired effect. So say you wanted Fade Off Screen and Fade In Fog, you simply add the two numbers together to get 20, and that's what you put as a value.
Number 2, Fade With Distance, has an additional parameter that needs to be added:
FlareNominalDistance 1 = The value is the distance in meters at which the flare totally disappears. Add this entry under the flare intensity entry if flare type 2 is used.

LensFlareOptions 7 = Works similar to above, but the LW code numbering system is too convoluted to be explained here. Just use the defaults for now.

FlareRingColor 80 20 10 = This is the color of the Central Ring when that flare option is used. It is in standard RGB format.

FlareRingSize 0.220000 = This is the size of the flare ring expressed as a percentage (22%). I don't know what this is a percentage of, however.

FlareStarFilter 2 = This is the visible distortion of the flare, how many points it has, etc. Options are:
0 - Off
1 - 2 Point
2 - 2+2 Point
3 - 4 Point
4 - 4+4 Point
5 - 6 Point
6 - 6+6 Point
7 - 8 Point
8 - 8+8 Point
9 - 10 Point
10 - 10+10 Point
You may only select one filter type, no combinations are allowed.

Choose numbers similar to the one's you see until you get some practice. Also if you look, these lights appear to be adding light to the scene (which they really shouldn't be doing), keep this in mind when trying to adjust your system lighting. It is important to note that these visible stars are not necessary to include in the scene file. If you don't want extra stars or don't care, don't waste your time creating them, you don't need to. Conversely, if you do want them, add as many as you like. Chances are you'll get tired of adding them long before you exceed lightwave's lens flare abilities. Just follow the format above (and of course give them unique names). I would like to point out a limitation in Lightwave scene lighting though. Lightwave scenes cannot have more than 8 lights total giving off light in each scene file. So, you can add all the lens flares you want, but you're limited in lighting.

More proprietary lightwave info. These sections are for lightwave use, not EoC use, and so are pointless to change. Even the camera.

Well that's it. I hope everyone has a little better understanding of the lightwave scene files as they relate to EoC geography and will have lots of fun making custom systems.

Oh, I almost forgot. Let me tell you what the numbers mean for star color in the .map file. The star color is an integer number in the range from 1 to 11. The way the numbers work is like this, they represent the RGB color scale but backwards (BGR) and without normal divisions. For instance; a star color of 1 represents a pure blue star, while a color of 5 to 6 represents a pure green star, and finally, a color of 11 represents a pure red star. A star color of say 9 will evenly mix green and red to give you a yellow star, and so on. So now you geog.exe users out there know how to get the star color you want.

I hope this post has been helpful and if anyone sees any errors in anything I've written please say so right away.

mailto:second_chance@cox.net

cartoons.sev.com.au/index.php?catid=4
.

Very cool info! Another way to think about star color it that it follows the rainbow (frequency spectrum) from highest wavelength to lowest (Blue Green Yellow Orange Red) (from hottest star to coolest star).

Has anyone noticed if star size is varying with the diameter, or the star color? (it is hard to judge with a glowing object).



-Gtrout

Thanks GTrout. But is this info very cool? I kind of get the feeling that nobody cared. Or maybe I didn't say anything everybody didn't already know. I wish there were more replies, good or bad, so I know if there's any point in posting stuff like this.

Anyway, thanks again GT. You always have something encouraging to say.

btw - brilliant analogy for the star color numbers, I'm glad you pointed it out.

mailto:second_chance@cox.net

cartoons.sev.com.au/index.php?catid=4
.

Well, it is going to be a bit like that. The number of people building a cluster right at this moment are probably 2 or 3. Including you and me.

But this info has never been collected before. And there are pieces of info here that I was not clear about. And now I know how to get a dim, but deep red glow in the Bumpy's Star system, even if I remove the star. So, it is cool. And useful, especially for those (like me) that forget things.

brilliant analogy for the star color numbers

Brilliant is too much credit. Just reporting the match between the star types and the color number. So someone could turn a star chart value into a star color number by looking at how the values line up. O(1) B A F G(5) K M(11). Which I think is how the designers looked at it. Otherwise, I expect the RGB would be in correct order.


-Gtrout

This info IS cool - for those who are able to follow.
Most players don't do the modding stuff - probably they never will.
It's a complex thing and rather hard to learn - you need SOME time and understanding.
Specially the younger generation is used to consume products prepared for consumption. Reading a book? No - watching TV or playing a videao game.
Reading about programming, understanding, learning, creating some stuff, failure, recalculating, failure, another recalculating , maybe partial success... - there is a lack of patience and perseverance.
Don't get me wrong - there are some genius guys around, doing this for hobby. But it's a minority!
It's a bit like the game itself. Most people who bought it where unhappy - they didn't manage to learn that unusual flightstyle, where kicked out by the first tutorial mission patrol squad, grumbled something like " this game *****" and moved on to freelancer. Some managed the tutorial and got mad about a lack of "savingpoints" - no patience, no perseverance.
"How the hell shall I get these fighters out of this maas base?"
Asking in a forum for a success-reproduction-cheat is usual.
If it's not possible to be successful in an easy way many people give up.
Grandpa is a really nice guy, encouraging everybody to grow. He should be a great father (or grandpa?)
But coming back to the floor - you are writing a contribution for a programmer minority in a player minority. Who shall comment your efforts? It will be GrandpaTrout, MajorTom, Shane, Hot4Darmat and maybe three other guys who understand what you are talking about.
The others wait for your modders guide, will probably give it a try, find out it's still some hard work to do and a minority will continue to be successful.
After a short market study you'll now your efforts will please a small and very specialized audience. You'll gain acknowledgment.

Who knows Peter Agre and Roderick MacKinnon without googling for them?

Do you enjoy the work you do? Great:D - go on. Are you satisfied with some acknowledgment from peoploe who know what you are talking about? In this forum you'll get it.
It can be a fascinating amusement to work on a very special theme just for yourself or to impress only one other person.
I am one of those guys who waits for a modder guide for EoC. I'll give it a try. Enviously looking at pics of new ships and mods with creative additions to the gameplay is a kind of motivation.

:DHey Second Chance - I'm waiting for your guide and I welcome your efforts.

no, no man im working on MP maps right now, and was havin a few probs, but i saw this and hit a gold mine of info, sorry i didnt reply i've been soooooooo busy at work the last 2 weeks i've barely been able to even come around and see whats up, anyway i printed out your post second_chance for easy reference when im not on my work pc , oh yeah and it IS very cool to me, to some people who have no interest in this kinda thing though its probably rather dull:D

"Faith lies in the ways of sin"