Spring RTS Engine

It might make more sense to invert the transparency as this method is counter intuitive OR fix the engine so 0 transparency or no alpha channel will work. We have all spent days tearing our hair to find this out.

Ok I guess that's better then... I have to say SJ picked the worst timing to go away, leaving us with a unit format we have to figure out

It's weird though, because intuitively I would say alpha=1 means full visibility, but apparently in PSP it means full transparency (invisibility).

The problem in 2 parts;

1. The numbers are really opacity not transparency.

2. When we try to set 0 opacity, the program or converter does not bother with pixels that you should not be able to see. Because we should see them, we just got things the wrong way around.

I'd done all my testing in 0 or 255 and got the blue or black like everyone else, then I noticed a sliver of some coloured pixels on an anti aliased edge. So I played with the values and found what works.

For a fix we need;

1. Textures to display if there is no alpha channel.

2. Invert the values of alpha if used so we can see what we are doing when we are drawing.

3. No weirdness like black textures when using values of 0 or 255 opacity/transparency.

So, let me get this stright... I tryed a PNG, and ticked the transparencey box when i saved... but what you actully ment was make the texture transparent, as Spring reads the value the wrong way round and so i need to make it fully not there to show up?

also, it likes the dds files fine and teh bmp for the second texture (reflectance and shinnyness) so i assume they work on teh first one to (though bmps cant have transparncy so not them...)

aGorm

Weaver wrote:... It was supposed to be a martian rock! ...

Looks like a rock to me. And a good looking one, too.

Weaver wrote:...
What to do with these?

Use them in maps placed in long lost civilizations? Like the tipical city maps of oTA.

aGorm wrote:So, let me get this stright... I tryed a PNG, and ticked the transparencey box when i saved... but what you actully ment was make the texture transparent, as Spring reads the value the wrong way round and so i need to make it fully not there to show up?

also, it likes the dds files fine and teh bmp for the second texture (reflectance and shinnyness) so i assume they work on teh first one to (though bmps cant have transparncy so not them...)

aGorm

You need to make a 0% opacity / 100% transparent alpha layer in your PNG.

FLOZi wrote:You need to make a 0% opacity / 100% transparent alpha layer in your PNG.

If 0% makes it black (it always did for me) then use a value a little higher.

My experience was from creating a png from a picture with a mask layer in PSP using 0-255 values of mask;

0 = black object
1 = your texture fully visible
.
127 = blended texture and team colour
.
255 = team colour only (usually blue when testing)

Which makes me wonder what you see if there is no team?

Hi, my question please...

Weaver, what software do u use to make model and uv texture of your model ?
Did anyone ever succeed making s3o model and uvmap it without using 3d MAX ?

maestro wrote:Hi, my question please...

Weaver, what software do u use to make model and uv texture of your model ?
Did anyone ever succeed making s3o model and uvmap it without using 3d MAX ?

I am using Wings3d and Upspring.

Upspring doesn't read Lightwave-exported OBJs.

Maestro send me a couple of OBJ files from lightwave, they are read correctly but they are all cubes... is this intended? If it's not then the lightwave exporter is not doing the correct thing, if it is then please send me some lightwave OBJs that it should read :)

Sean, Upspring can read Lightwave .obj properly....
what it cant read is lightwave UV system. U can make the model in lightwave then u need to uv it in other software

Lightwave UV is unique that every polygon in the uv mesh is independent from other (u can move an uv polygon without changing anything else)
so it uncompatible with other format in uv stuff

Zaphod, did Upspring read Blender UV properly ?
Which is better to be abused as UV engine, blender or wings ?

my planned workflow will be :

Lightwave (modelling) ----> Blender/Wings/UVmapper (whichever work better) as uv mapping software -----> Upspring

Something I dont really understand in blender is how to build hierarchy in it ? or we dont need to build hierarchy to make proper uv in blender for a kbot ?? just uv it directly
Also how to assign pivot in blender/wings ?

UVmapper isnt much help since we can use the texture as background

I have never uv-mapped anything so I don't know what is better.
You don't need to make a hierarchy in blender because you can never store it in the OBJ and get it to upspring. (Because OBJ doesn't support an object tree)

If it would be possible to model in LightWave, and then texture, and directly export from there to an s3o file, that would be very useful. Same goes for MilkShape3D, only the texturing tools in MS3D are kinda weak.

Ive told zaphod before...
best option is if Upspring have its own internal UV mapping program

but maybe that need additional programmer.....
If im a programmer i would help him with that
but the only language i know is basic of BASIC

The absolutely best would be to have Spring use a common and widespread model format like quake mdl, or md2, since polycounts are roughly adequate, and exporting tools exist in many forms. This would also make skeletal animations possible, and make piece tree generation even easier. As for unwrapping, I doubt many of us could do a better job than professional programmers who did Lightwave or 3ds Max.

Hi Zaphod & Sean, Evaluator here....
I figure out how to make spring model with Lightwave
need a few trick with UV though, but that is an easy one :)
gonna make some tutorial for you two :)
unfortunately, ATM lightwave obj's uv map cant be read by Upspring
so I must triangulate the object and export them as 3ds only

To zaphod, when i tried export unit I choose a file type
the software still want as to write extension in filename, otherwise it will give 'unknown extension' message.... so even u have choose .s3o in the save as filetype drop down you still must write 'filename.s3o' in file name

Also : since I can only use triangle based object, how many it will cause inefficiency in SPring engine ? or it is not a problem much and number or vertex is all that counts in spring uv engine ?

To zaphod, when i tried export unit I choose a file type
the software still want as to write extension in filename, otherwise it will give 'unknown extension' message.... so even u have choose .s3o in the save as filetype drop down you still must write 'filename.s3o' in file name

Ok I understand, I'll fix that for a next version...

I thought about making UV mapping easier without building a whole UV mapping suite into upspring... I could support exporting merged version of all the objects into one... and then reading the UV coordinates back from this object to the seperate objects. Let me clearify:

- user selects "Write UV mesh" in the menu
- temporarily all the pieces are merged to a single piece and saved to an OBJ or 3DS file
- user UV-maps this single piece with his UV mapping software
- user then selects "Load UV mesh" in the menu and selects the UV-mapped OBJ or 3DS file...
- the UV coordinates are read back from the OBJ/3DS file with a single pieces to the model in upspring with seperate pieces.

So you basically don't have to do everything per-object. That would save a lot of time right?

Umm good Idea but not much help ATM as upspring fail to read the uv of a single box

There is a problem using s3o's as feature, the faces are back to front!




Clockwise...

1. Object before placing - has the no texture look.

2. Object placed - all good.

3. Object as feature - faces back to front!

I'm guessing that the unit faces are also "back to front" only you don't notice it because backfaces aren't culled for units but they are culled for features apparently...
Just select all polygons and flip them in that case....

maestro, I will do another bugfix release soon, you're right about the UV coords...