Sharing texturemap globally with all features...?

[FLOZi]

We called them elmos in TA long before spring came around.

I don't know if a TA elmo and a Spring elmo are the same off the top of my head, though.

Also this is a stupid idea, just uvmap the features normally, christ

I never heard them called elmos in TA

[Gnomre]

11:03:16 AM gnomre: hell maybe i'm wrong then, whatever
11:03:34 AM gnomre: trademark is still a retard, i just have occasional wrong memories

[TradeMark]

yeah cover your failure by insulting me... go for it... i dont care.

--

now back to business:

i need some help with this file format, its kinda confusing, for example:

int vertexTable; ///< file offset to vertice table, vertice table is made up of dwords indicating vertices for this piece, to indicate end of a triangle strip use 0xffffffff

these dwords are pointers? and they point to this kind of data:

Code: Select all

/// Vertex structure for .s3o files. As far as I (Commander) can tell, this is never actually used.
struct Vertex{
	float xpos;		///< position of vertex relative piece origin
	float ypos;
	float zpos;
	float xnormal;		///< normal of vertex relative piece rotation
	float ynormal;
	float znormal;
	float texu;		///< texture offset for vertex
	float texv;
};

? or what did i miss...?

And why theres two identical vars:

Code: Select all

int numVertices;	///< number of vertices in this piece
int vertexTableSize;	///< number of indexes in vertice table

or in what way they differ?

[jK]

Why the hell are you analyze the file format???

There is UpSpring and a blender plugin to export stuff into s3o!

Or do you really think modelers `write` their models in a hexeditor?

[smoth]

It was a term created because I was sick of people acting stupid about the f-ing TA scale and spring and since we were unsure at the time if the unit measurement was pixels or what I made a post:

http://springrts.com/phpbb/viewtopic.ph ... mos#p60332

Now for fucks sake just get over it.

[FLOZi]

Why the hell are you analyze the file format???

There is UpSpring and a blender plugin to export stuff into s3o!

Or do you really think modelers `write` their models in a hexeditor?

The official verdict from the community is that Upspring is buggy as hell.

[TradeMark]

Why the hell are you analyze the file format???

There is UpSpring and a blender plugin to export stuff into s3o!

Because i am autogenerating the models from a data i have?

It's about 9001 times faster than copying the models by eye into blender and then saving them separately and then testing which is the correct height offset for the origin in that position of the heightmap, and which is the correct model position and so on.

+ for future use its much more fun to just press a button! than do hours of work for some other city map.

+ i have an editor to edit the city, all i need to do is to split the city in parts which each of them is a feature in Spring.

- i havent tested this idea yet, not sure how spring manages to draw 60 big and unique features with decent amount of triangles in each of them.

Or do you really think modelers `write` their models in a hexeditor?

No... do you think i really am retard?

--

Now, can someone finally help me in this file format thing?

[Argh]

I could say a bunch of Obvious stuff, but a screenshot is easier:


World Builder. Use it. Contribute your shared-texture buildings, and I'll be happy to integrate them and build normalmaps. This entire scene took about an hour to build, down to the last fricking street-light.

Or wait for Smoth to get done with whatever he's doing. Whatever. Your ideas for implementation are so far making no sense at all, though. There are no serious performance advantages to giant, poly-heavy Features in terms of GPU, and there are serious disadvantages.

[TradeMark]

World Builder. Use it. Contribute your shared-texture buildings, and I'll be happy to integrate them and build normalmaps. This entire scene took about an hour to build, down to the last fricking street-light.

Or wait for Smoth to get done with whatever he's doing. Whatever. Your ideas for implementation are so far making no sense at all, though. There are no serious performance advantages to giant, poly-heavy Features in terms of GPU, and there are serious disadvantages.

Notice that i have no experience in modelling, so it would take 100h while it takes 1h for you.
For me its faster i make a program to write the files, so, just answer my questions about the file format and i can get working on it, damnit :D

And im not gonna wait some Smoth to do whatever hes doing, wtf? xd

I'm about 2 variables far away of creating my map in 30 seconds... so if someone could just help and explain those variables clearer i wouldnt bother you any more, and in a while you would get an awesome spring map to play on!

I am lazy guy... i dont want to model anything like buildings by hands, i rather make editor to make the buildings and press a button
(lazy guy syndrome includes learning how-to-use some other programs...)

[Argh]

Do you understand that your buildings won't be Features that properly interact with everything from POV to Unit movement?

I mean... it's one thing, to make / display some custom display list... it's a whole 'nother story, to make it all properly interact with the rest of the engine.

Anyhow... what variables are you stuck on...?

[TradeMark]

Do you understand that your buildings won't be Features that properly interact with everything from POV to Unit movement?

yes they do, i have heightmap inside the buildings lol. the features itself wont have any collision set on them.
i can even build on the features :O EPIC WIN!
the map is set to undeformable, so when you start building on a feature, it wont reformat the ground again... which would look shit.

Anyhow... what variables are you stuck on...?

i need some help with this file format, its kinda confusing, for example:

int vertexTable; ///< file offset to vertice table, vertice table is made up of dwords indicating vertices for this piece, to indicate end of a triangle strip use 0xffffffff

these dwords are pointers? and they point to this kind of data:

Code: Select all

/// Vertex structure for .s3o files. As far as I (Commander) can tell, this is never actually used.
struct Vertex{
float xpos; ///< position of vertex relative piece origin
float ypos;
float zpos;
float xnormal; ///< normal of vertex relative piece rotation
float ynormal;
float znormal;
float texu; ///< texture offset for vertex
float texv;
};

? or what did i miss...?

And why theres two identical vars:

Code: Select all

int numVertices; ///< number of vertices in this piece
int vertexTableSize; ///< number of indexes in vertice table

or in what way they differ?

[Argh]

yes they do, i have heightmap inside the buildings lol.

You're going to be sooooo disappointed.

Oh well, I'll let you learn why the hard way. This whole "auto-generation is going to save me time" is basically a chimera. Even doing it with auto-build algorithms that adjust to the map's conditions (something that's still in World Builder, I just don't use it any more) is not terribly satisfying vs. doing it manually. It's like you're going through every painful step I took, only you're making it even harder for yourself...

As for your question... you don't need to do any of that. Just build your meshes that fit the heightmap. Place the Feature using Lua or a SMF featuremap. Done.

Or even better yet... if your buildings are scaled on a precise grid vs. heightmap squares, just place them arbitrarily and use Lua to alter the heightmap based on the Feature's current position.

[TradeMark]

yes they do, i have heightmap inside the buildings lol.

You're going to be sooooo disappointed.

Oh well, I'll let you learn that the hard way.

As for your question... you don't need to do any of that. Just build your meshes that fit the heightmap, and draw it with the engine. Place the Feature using Lua or a SMF featuremap. Done.

Or even better yet... if your buildings are scaled on a precise grid vs. heightmap squares, just place them arbitrarily and use Lua to alter the heightmap based on the Feature's current position.

yes, thats what im doing? but im not gonna use lua. i will just set the origin in that kind of place which makes it rendered correctly ingame...
whats so hard in that? shouldnt be impossible, unless spring adds some random values to just fuck with me xd

As for your question... you don't need to do any of that.

How i exactly export my data into s3o if i dont know how to make s3o file? ...


+ you shouldnt be concerned about my disappointment this might lead to, because i dont care, i just want to see if this works.. if it doesnt work, i will just move on some other things... this is just an experiment, and, do you want me to stop learning how to mod Spring ;_;

[Argh]

How i exactly export my data into s3o if i dont know how to make s3o file? ...

Do you have model meshes with skins? Put the meshes + skins up, and I'll convert them to S3O in about 10 minutes, unless you're using some ultra-extreme file format.

Then you can either combine them into grids of static Features, saved as S3O, or better yet, use a Unit saved as S3O, and then use BOS to randomize their grid assignment every time, and use each Piece origin + Lua to alter the heightmap, for a perfect fit no matter where you put the grids.

Basically, though... you're going to be very disappointed with the heightmap approach. But this is something you obviously want to learn the hard way, and if your chief problem is converting some models, I'm willing to help.

[TradeMark]

How i exactly export my data into s3o if i dont know how to make s3o file? ...

Do you have model meshes with skins? Put the meshes + skins up, and I'll convert them to S3O in about 10 minutes, unless you're using some ultra-extreme file format.

i dont even have models. i wrote the vertex data for each cube style by hands already (about year ago). the maps are from some other game.

all i have is data, data, lots of data! then i loop through that data, get the correct shape for cube, use my cubedata array to get the vertex positions, set texture coords on them regarding to the data i am reading, and then tadaa!

and i dont care if someone already made some convertor to this (which i highly doubt), i want to do it myself. damnit.

[Argh]

So... you have some cubes... as vertex data... and some textures which precisely fit the cubes.

Just export the vertex positions as simple OBJ format, then convert to S3O.

Or just show me the textures, if the buildings are just cubes then it's really trivial.

[TradeMark]

each cube has 5 sides that can have a square tile texture on them.

dude, im not going to use any third party program if i already am almost done with s3o file writer xd

and the texture is 1024x1024 tilemap, has about 142 tiles in it

[Argh]

Do you realise that S3O doesn't support tilemaps?

You can use a texture with all of the teeny tiles, that's fine. But S3O won't let you use tiling textures. If you want that, you need to implement it yourself, using Lua --> gl.Unit.

[TradeMark]

it doesnt matter how i call it, tilemap or anything, i just use uv-coords to get texture from that "tilemap" which has 142 square textures in it...

[Argh]

Question... do you repeat a texture multiple times per quad, though? For windows, etc?

If so... you're doing something S3O doesn't support, as a file format.

And no offense, but if you'd be so kind as to show us a screenshot of whatever these buildings look like, in the old environment, it'd be a lot easier to know how to help you.