Asteroids [NEEDS INTEGRATION]

[Deus Siddis]

Update: After much distraction, redesign and procrastination on my part, this asteroid content pack is finally complete and ready for download:

Asteroids Sources

Asteroids BFXMs

Released under the GPL v3, be sure to read the "Manual" document that comes inside the pack, especially the "instructions" section included therein.


- - - - - - - -

I have been working on new asteroid models and textures and I think I have refined and expanded the method charlieg suggested in this thread, into a fairly accurate looking, pleasing and still relatively gpu-sparing method. Example:



Each is 1000 (or 4000 if we want smoother silhouettes) faces for the top LoD, 240 for the middle and 80 for the bottom, with each LoD coming labor free for each asteroid since the subsurface modifier is used in creating them before export.

The only real expense comes from the textures, which for the few but huge asteroids whose diameters are measured in kilometers, should use the top level texture LOD size of 2048x2048 for diffuse and specular and normal. A similar resolution might go a long way for the detail textures as well, assuming such is possible with modern hardware.

To compensate, it is possible to use only one set of textures for all of the asteroid models in an asteroid belt, this set of 'omni' textures baked from the icosphere said asteroid models were originally mutated from. This saves huge on texels, but creates some distortions as you can see from the following example:



Also, I can bake a variety of different textures to roughly represent different types of asteroids and compositions, like C, S, M, E and D types, Magnetite, Albite, (gold) Enstatite, Olivine, (blue) Pyroxene, Andesine, (purple) Jadeite, etc. Some of these could be used to bake the smaller, cheaper textures of various types of valuable and tractor-able asteroid-fragment objects if a brave and noble coding soul wants to implement asteroid mining gameplay (looking at units.cvs, there is evidence this might already be partially implemented).

There is still room for future improvements, like geometric craters and crystals or a pallasite texture, but such further improvements will require some actual handwork. That aside, I would like to get these in for 0.5.1, I think they are enough of an improvement over the current asteroids to be worth committing.

So I await whatever official approval is needed and instructions or coder collaberation as to the scales, resolutions, number of different models and which asteroid Types are wanted for future versions of Vega Strike.

Also Chuck, let me know what interest PU has in this content.

[Fendorin]

they are very nice

i had create some "generic" in the thread http://vegastrike.sourceforge.net/forum ... 46#p106446
for did a Extraction field for render a "huge station" in fact a asteroid field with some extraction tools landed on bigger asteroid but i m not so happy to the asteroid render

Then if we can combine your asteroid and mine "station"

the render will be nice

post your file and the map when they are finish
and yes a different color should be very good for various effect

[pyramid]

They look very nice. Later, I could provide some hi-res maps generated procedurally with my asteroid pov-ray script, though I'd require to tweak some code first. When using 1 texture set for all asteroids in the same system (high probability of equal material occurrence), 2048x texture resolution sounds just fine.

[Deus Siddis]

they are very nice

i had create some "generic" in the thread http://vegastrike.sourceforge.net/forum ... 46#p106446
for did a Extraction field for render a "huge station" in fact a asteroid field with some extraction tools landed on bigger asteroid but i m not so happy to the asteroid render

Then if we can combine your asteroid and mine "station"

the render will be nice

post your file and the map when they are finish
and yes a different color should be very good for various effect

Sure thing, improving the asteroids of asteroid bases was what kicked this off in the first place.

They look very nice. Later, I could provide some hi-res maps generated procedurally with my asteroid pov-ray script, though I'd require to tweak some code first.

I don't think you'll need to worry about that, since these textures too are procedurally generated, only in blender, and such being the case I can make them any resolution you want. When I'm done organizing them I'll turn in the source files, so anyone else can do the same if so they wish.

When using 1 texture set for all asteroids in the same system (high probability of equal material occurrence), 2048x texture resolution sounds just fine.

Excellent.

[Turbo]

These look very good. I can't wait to have some target practice on them.

[Deus Siddis]

C-Type Carbonaceous Chondrite Asteroids:



Magnetite Asteroids:

[Deus Siddis]

M-Type Nickel-Iron Asteroids:



V-Type Pallasite Asteroids:

[Phlogios]

Try to implement them in the game, so we can see how they render real-time

[Deus Siddis]

Try to implement them in the game, so we can see how they render real-time

I have tried and failed.

While I have mostly attempted to use it through Unit Converter, I am almost certain the problem is with mesher itself, because when I try to double click on mesher (in the bin directory of VS with all the .dlls) to open and run it, nothing happens except a black python or dos window comes up for a millisecond and then vaporizes. The "uc" batch file in unit converter also crashes in the exact same way (from what I can tell, since I can't read in milliseconds), but unit converter comes up fine if I run it by opening "unitconverter.py", so there might not be any connection.

Maybe it is all because I am using python 2.6.1? Or is mesher purely C++ anyway?

[loki1950]

Mesher is all C++ it's just pyramid's GUI that is written in python and that millisecond cmd prompt window is normal behavior if you don't feed it anything to mangle(err mesh) we really need a new windows binary for it though as the current one does not support all the new capabilities of the engine we should see some movement soon as kluass has finished his stint as a teacher and should now have more time for VS

Enjoy the Choice

[Deus Siddis]

Mesher is all C++ it's just pyramid's GUI that is written in python and that millisecond cmd prompt window is normal behavior if you don't feed it anything to mangle(err mesh) we really need a new windows binary for it though as the current one does not support all the new capabilities of the engine we should see some movement soon as kluass has finished his stint as a teacher and should now have more time for VS

Well I think I found the problems, it doesn't like the white space in "Vega Strike" and it doesn't like for mesher or anything to be on an external hardrive.

So I was finally able to export an asteroid mesh into bfxm format, and replaced the old model and textures with it, loaded the game and went to the field in Cephid 17, to find the models rendering okay, except that they have no textures.

I could understand the tangent space normal map not coming through, since that is a newer feature, but not even the diffuse or specular rendered, the asteroids were a plain white. I didn't compress them, maybe the game no longer reads textures anymore that are not hardware compressed?

[loki1950]

Check the path to those textures in units.csv and the log files they should give you an indication of what the engine thinks it is doing and maybe why it is not loading them.Leaving them uncompressed should not be a problem.

Enjoy the Choice

[Deus Siddis]

Check the path to those textures in units.csv

I only dropped my asteroid model in place of the old one, roid2.bfxm, with the same name in the same directory. BTW, there is no path to textures in units.csv that I can see, it only points to a directory and the name of the bfxm, so I would assume that the bfxm is all that points to the texture file names, and assumes its textures are in the local directory.

and the log files they should give you an indication of what the engine thinks it is doing and maybe why it is not loading them.

Where are those log files or what are they called?

[loki1950]

The second column of units.csv is used for Directory and i see that asteroid fields are factional so that may be the complication the logs are in the bin directory and are called stdout.txt and stderr.txt

Enjoy the Choice

[Deus Siddis]

The second column of units.csv is used for Directory

Right, but if that is wrong, you shouldn't see any model at all, since that is where the model is stored too. I'm seeing the model, it just doesn't have any textures. It is rendering a blank white.

and i see that asteroid fields are factional so that may be the complication

Apparently not, I just replaced the fighter barracks (which to my knowledge uses no factional texturing) with my asteroid model and textures and received the same result- model with no texturing.

the logs are in the bin directory and are called stdout.txt and stderr.txt

The only thing that comes up is the following from stderr.txt:

Code: Select all

Less Fatal error: drawing ship that has a nonexistant tex

But I'm not sure what leads this provides as to why it thinks the texture is nonexistant.

[pyramid]

I've tested the files you emailed me.

What I did:
* Clear workspace
* Add model: asteroid.obj
* Add textures: a) diffuse: stype_diffuse.png b) spec: stype_specular.png
* Save and Convert
* Copy Data
* This is important: set unit role: FIGHTER
* View
* (in VS) press "6" key to view the asteroid as it is registered as a vessel when you follow the quick way outlined above

[Deus Siddis]

I've tested the files you emailed me.
What I did:
* Clear workspace
* Add model: asteroid.obj
* Add textures: a) diffuse: stype_diffuse.png b) spec: stype_specular.png
* Save and Convert
* Copy Data
* This is important: set unit role: FIGHTER
* View
* (in VS) press "6" key to view the asteroid as it is registered as a vessel when you follow the quick way outlined above

I have done all of the steps you have outlined and nothing else, but the model does not appear in the view mission, not in any camera view.

I found the following in stdout:

Code: Select all

CREATING A LOCAL SHIP : Asteroid
Hi helper play 0
HereUnit file Asteroid not found

[pyramid]

In this case you might try pressing "Save" in the Units screen and then verify if the Asteroid entry is in your units.csv.
Do you run the latest UC version (v0.38)?

[Deus Siddis]

In this case you might try pressing "Save" in the Units screen and then verify if the Asteroid entry is in your units.csv.
Do you run the latest UC version (v0.38)?

Okay now the View option works straight out of UC, that's one mystery solved. Thanks. (And yeah, I am using the latest UC, 0.38)

Unfortunately though, my new asteroid fighter is still rendering without either the diff or spec textures, it is just a plain white.

[pyramid]

Hmm, have you checked the "bypass compression" box under "Config"?
Try also checking "create xmesh files", then save and convert and check if the texture reference in the xmesh file is pointing to your uncompressed pngs.
Can't think of anything else right know.

[Deus Siddis]

Hmm, have you checked the "bypass compression" box under "Config"?

Yeah, that was one of the first things I did.

Try also checking "create xmesh files", then save and convert and check if the texture reference in the xmesh file is pointing to your uncompressed pngs.

Umm, hmm, it looks like the xmesh file doesn't make any reference to my textures at all. I had assumed this was natural, that xmesh was exclusively a mesh file. This is all it says on the subject:

Code: Select all

<Mesh scale="1.000000" reverse="0" forcetexture="0" sharevert="1" polygonoffset="0.000000" blend="ONE ZERO" alphatest="0.000000" >
<Material power="100.000000" cullface="1" reflect="0" lighting="1" usenormals="1">
	<Ambient Red="1.000000" Green="1.000000" Blue="1.000000" Alpha="1.000000"/>
	<Diffuse Red="1.000000" Green="1.000000" Blue="1.000000" Alpha="1.000000"/>
	<Emissive Red="0.000000" Green="0.000000" Blue="0.000000" Alpha="1.000000"/>
	<Specular Red="1.000000" Green="1.000000" Blue="1.000000" Alpha="1.000000"/>
</Material>
<Points>

After that it just goes on listing points and quads.

[pyramid]

Hmm, smells like a mesher problem to me, assuming that the obj and mtl files are ok (since they work for me).
You may try testing manual convert using the attached obj and mtl files issuing the command (mesher oxc asteroid.obj asteroid.xmesh) or analogous for the bfxm (mesher obc asteroid.obj asteroid.bfxm) after confirming that the xmesh actaually registers the textures. If not, it is really mesher related.

[Deus Siddis]

Hmm, smells like a mesher problem to me, assuming that the obj and mtl files are ok (since they work for me).
You may try testing manual convert using the attached obj and mtl files issuing the command (mesher oxc asteroid.obj asteroid.xmesh) or analogous for the bfxm (mesher obc asteroid.obj asteroid.bfxm) after confirming that the xmesh actually registers the textures. If not, it is really mesher related.

Okay, it look like this problem is with mesher- it won't convert the texture information from the .mtl to the .bfxm at all. So what I had to do was convert obj/mtl to bfxm, convert the bfxm to xmesh, edit in the textures as follows:

Code: Select all

<Mesh scale="1.000000" reverse="0" forcetexture="0" sharevert="0" polygonoffset="0.000000" blend="ONE ZERO" alphatest="0.000000"  texture="stype_diffuse.png"  texture1="stype_specular.png" >

And then I converted back to a new bfxm (after thowing the old away to not confuse them) and then converted this corrected bfxm back to xmesh to see if the texture data was still intact (it was the same, exactly as quoted above). Finally, I put the new correct bfxm in the place of the old bfxm created by UC as the asteroid "fighter" (recall that this unit was made/setup using the bypass compression option in UC) and started up UC's "View" feature to see how it all looked in the game. . .

It renders as an asteroid with, instead of a plain white, a plain gray material, no texturing. It would appear to me that there is another, different, new problem that is preventing even one of the most basic texture types from rendering as anything more than a flat gray. . .

. . . . . . . . . BAAAAAAAAHHHH!

[Deus Siddis]

Alright, so when I check the "Bypass compression" option in UC, which of VS files does that change to make this happen? How do I tell VS, without using UC, not to worry about texture compression in general or for a particular unit?


BTW pyramid, this is unrelated to the content pipeline, but I noticed that the planetary textures have a 2 to 1 aspect ratio being 2048x1024. Does VS' opengl graphics engine allow the use of such nonsquare textures in game? Or does it convert them each to 2048x2048 square textures at runtime and you used the smaller nonsquare textures simply to spare user hardrive space and download time.

[pyramid]

Re: vs textures. The reference for textures is stored in the xmesh or bfxm files by the file name. The extension has no significance since the engine recognizes the format by the magic number stored in the file header. So, what the "bypass compression" option essencially does is just avoiding the extra step of compression from png to dds.

Re: planet textures. The only requirement is that textures be POT. See e.g. the planet rings textures, they are 64x2048.
What you need to assure when deciding texture size is the ratio of texture pixel to screen pixel. For planets you wrap the texture 360 degrees along the equator and 180 pole-to-pole. With a 2:1 texture you avoid pixel stretching; that is the reason for the selected ratio.