Punching in some strangelet models, need expert assistance.

[Zeog]

About that dome texture: I noticed when updating from SVN that there is that very same honeycomb dome texture that you were missing for the agri-dome in the diplomatic station's texture. The diplomatic station doesn't show that part of the texture in your screen shot. Maybe Strangelet was sharing textures?

[Halleck]

Wierd... that one doesn't have an alphamap, though. I'd need one to make any use of it.

[Zeog]

Here is a quick'n'dirty version with alpha channel.
It's just made of hexagons used for a bumpmap with gimp.
I just realized that it's not of the right size though...

[Zeog]

Alright, here is a better and much larger one. Feel free to use it!
http://www.deeplayer.com/Vegastrike/Res ... eycomb.png (1.2MB)

[Halleck]

I'll try this... VS probably won't like it though, textures are supposed to be square and use powers-of-two. (512x512, 1024x1024, etc.)

[Halleck]

Alright, here is a better and much larger one. Feel free to use it!
http://www.deeplayer.com/Vegastrike/Res ... eycomb.png (1.2MB)

Cropped the texture to 1024x1024 and it actually looks pretty good. The tiles could stand to be smaller, I can try cropping to a large square and resizing to 1024x1024. Doesn't look like it tiles at all so a crop should not create any problems.

Here's a shot similar to the old one for comparison:


Wait, what's that?


Oh no... looks like the outside is on the inside! It's like an Escher drawing.


There is something screwy going on with the draw order, or the z-buffer, or something of that nature. From that last picture, it seems like it is drawing the closest object first, the further one second, and the farthest one last. This needs to be reversed for it to stack correctly.

Also: notice that there are no artifacts.
I wonder why... I'll have to compare this to the scaffolding PNG.

[Zeog]

Yeah, the hexagons have to be much smaller in order to look like the original rendering.
So here it is: a much smaller honeycomb pattern in a darker color and 2048x1024 pixels at 80 kB . This pattern is tileable but a tile probably wont be of power-of-2-size, I haven't tried it yet. So if you can change texture coordinates a small patch should be sufficient.

Grab it here: http://www.deeplayer.com/Vegastrike/Res ... eycomb.png

[Halleck]

Good, now we're getting somewhere...

First I'm gonna have to ask you to make your future textures square, at least any you plan on having me use. This is, predictably, what happens when you plug in rectangular textures into the space for a square texture:


After cropping it to 1024x1024 it looked pretty good, but it's a pain to have to do that each time.

Anyway, here's the latest shot, which I oriented for easy comparison with the render.


From a purely objective standpoint, there are currently only three differences between the in-game model and the render:
1. The hexagons are slightly smaller
2. The terrain doesn't have any water, and doesn't look as good in general
3. The grass is missing

Not bad considering the circumstances.

Of course, these can easily be fixed if strangelet decides to send us the missing textures.

Back to problems with other models:
1. There are y-axis positioning problems with the landing strip on gas mine... doodads are too low into the floor, or the floor is too high. Lights are also too high and too far forward. Also, you can't see the textured landing strip for some reason.

2. The ishmael's scaffolding kind of looks wierd, I'm not 100% sure the texture is applying correctly. They seem frail... maybe I should give them a decent specmap. (they might also be subject to this wierd draw order bug.) Also, I need to remove the "engine" cones.

3. I still can't get the turret meshes to convert to bfxm.

[klauss]

Draw ordering: You have to use blend="ONE ZERO", and set alphatest="0.5".

About mesher, I'll keep trying to solve it at home. I'll try to set up a test system so that you don't have to play the lab rat part.

[Halleck]

At last! The latest mesher binary you sent works admirably.

I tried using the alphatest thing. It fixes the draw order problem:


Now there's some sort of draw distance issue though. As I travel away from the domes, they slowly vanish.


I'm not sure which is better. SRCALPHA seems to make it a bit softer looking, which is nice from far away. I think I'll stick with the alphatest one for now, maybe you can fix it up. (Or I can just wait for OGRE.)

[Halleck]

I've been putting that new mesher binary through its paces, and so far it's been running nice and smooth.

I've gotten ALL of strangelet's turrets in-game:


There are some problems, though. The UV maps apply fine in some places, but in others they are clearly distorted (often in the back). It's possible that when I converted his 3ds file into OBJ, the converter messed up some of the UV coords...

If that's the case, this is beyond my expertise and time available to correct. Either someone would have to convert these back to OBJ and fix the mappings, or someone with 3DS MAX could try exporting them as OBJs. (I had to use a crappy external converter.)

Still, I think that these look okay from a distance, which is where you'll be seeing them most of the time. The railgun is the biggest issue, the texture on the rail is all screwy and distorted.

I'm also not sure if I set them up right from a game unit standpoint. I'm unfamiliar with the whole subunit system, I just treated these like regular ships.

One more question: where should I put these to commit them? I have them now in /units/subunits/turretwhatever/. Inside turretwhatever is whatever.bfxm and strangelet's texture with its original name.

Ex. /units/subunits/turretrailgun/ contains:
railgun.bfxm
wep-rail.jpg

Okay... phew. I'm exhausted, that was a huge amount of work. I sleep now.

[klauss]

There are some problems, though. The UV maps apply fine in some places, but in others they are clearly distorted (often in the back). It's possible that when I converted his 3ds file into OBJ, the converter messed up some of the UV coords...

I've seen it happen on otherwise OK models, so it must be another mesher thing. I have an idea of what it could be... so stay tuned

[Paslowo]

I played around with OpenGL before and it appears to be a common problem for me as well when I was trying to make a seperate game.

The transparency things seems to drive a lot of people nuts.. The only solution possible are, sort out all the polies, or get a new 3D rendering engine.

[klauss]

or get a new 3D rendering engine.

Where did you get that it is an option?
It's an algorithmic problem - no way to solve it. Either have "pixel stacks" (totally unrealistic with modern hardware), or live with it (sort polies).

The solution is indeed alpha testing. The solution to alpha testing's inherent hardness (what makes it eventually disappear when the mipmapped alpha channel falls below the threshold) is a new stuff nVidia hardware has (or was it ATI? Can't remember) that provides alpha-test-friendly antialiasing. Your problem, indeed, is that alpha testing inhibits proper filtering.

Hardness (aliasing) is unavoidable, but you may avoid dissapearance, changing the threshold. You could try 0.1 (though it might be 0.9 - can't remember which way it has to go ).

Anyway - there are few other options. One of them, I think, is dividing the domes in sections (I think two halves is enough, but I'd have to think carefully about it to be sure), and going back to alpha blending. The other option is sorting out all triangles - actually, it's the only option, but dividing each dome in halves achieves that, actually, since "submeshes" are sorted out by the engine (both engines, VS and Ogre, sort out transparent submeshes... you can't sort out triangles with modern hardware - it's too expensive).

In ogre, actually, you can have a hybrid: alpha blending and alpha testing - it would help smooth out the thing in most cases, while still avoiding sort order abherrations, with the cost of small glitches, which I could certainly live with.

[klauss]

There are some problems, though. The UV maps apply fine in some places, but in others they are clearly distorted (often in the back). It's possible that when I converted his 3ds file into OBJ, the converter messed up some of the UV coords...

I've seen it happen on otherwise OK models, so it must be another mesher thing. I have an idea of what it could be... so stay tuned

I've been looking into the matter, and found out what I already knew, but had forgotten: the bug is the other way around - texturing seams break smoothing groups, but texturing itself remains as it should. Therefore, I am oficially puzzled - perhaps it's as you suspected, perhaps the 3ds->obj converter messed up somehow.

EDIT: Ya... quite probably it's the 3ds->obj conversion - Blender also sees textures that strange with the railgun, and I've confirmed that mesher doesn't bork up texture coordinates anymore (I fixed it a while ago). I've seen the option to import 3ds into blender, though - you might want to check that out (and do the conversion with blender - it may be more dependable).

[Halleck]

I can give it a shot. Haven't had very much luck with blender import scripts in the past, though. The only ones that have worked for me are OBJ and LWO.

Before I go and do it all over again though, I'd like to make sure I'm setting up the turrets right. After inspecting some of the other turrets, it looks like they are split into a "turret" and a "gun" subunit.

So, would I do obj->bfxm->xmesh, and then convert the two resulting submeshes (conveniently, base and gun) into two seperate BFXMs that go in two seperate folders?

How do I tell the game that these subunits go together?

Also, where in the dataset should I store the textures for these turrets?

[jackS]

I can give it a shot. Haven't had very much luck with blender import scripts in the past, though. The only ones that have worked for me are OBJ and LWO.

Before I go and do it all over again though, I'd like to make sure I'm setting up the turrets right. After inspecting some of the other turrets, it looks like they are split into a "turret" and a "gun" subunit.

So, would I do obj->bfxm->xmesh, and then convert the two resulting submeshes (conveniently, base and gun) into two seperate BFXMs that go in two seperate folders?

How do I tell the game that these subunits go together?

Also, where in the dataset should I store the textures for these turrets?

You want one BFXM for each rigid object, hence 2 for these turrets. They're associated with each other in units.csv. The guns are a subunit of the turret base. That's how we allow for them to move independently in the current implementation.

As for where to put everything... keep them all in one folder if it's easier for you to reason about shared resources (textures/base vs. the guns themselves) - but it might be simpler to just put them in their own folders, like the rest of the turrets. All of the turret directories are in data4.x/subunits. You should put them there, as per the existing turrets. IIRC, the only things that depend directly on the directory structure are the per-faction models/textures.

For the moment, store the textures with the models. Any meaningful attempt to organize all of the textures into a coherent package and share resources intelligently is going to require enough of an effort that it's not worth fretting over whether this current action increases or decreases the later effort.

[Halleck]

Okay. The bases are pretty similar texture-wise (and as far as I can tell, geometrically identical.) I might be able to get away with a shared base unit... say, turretstrangelet (or a more appropriate name if someone can come up with one), and have a seperate folder for each gun if that's possible. I could also just lump them into one folder like you suggested- whatever's easiest to maintain. Currently in my SVN sandbox, I have them in their own /units/subunits/ subdirectories along with the textures, but each BFXM includes the base and the gun, as pictured.

Once I get the meshes divvied up properly, I'll try making a dummy unit to test the turret. Not quite sure how to get it onto a ship for use, though, but I might be able to figure it out. I never really used turrets in the game, so testing these out will be... interesting.

One more thing, do I have to add an entry to /units/subunits/size.txt?

[klauss]

Try, if you can, to use direct obj->bfxm conversion.
You can do most of what you want by editing the .mtl file (I mean, assign textures and all).

Useful Commands in .mtl:

Code: Select all

MAP_KD <diffuse map>
MAP_KE <emissive (glowmap)>
MAP_KS <specmap>
MAP_KA <damagemap>

The obj->bfxm preserves the exported normals, for instance, and in general is cleaner than obj->xmesh->bfxm.

[Halleck]

Try, if you can, to use direct obj->bfxm conversion.
You can do most of what you want by editing the .mtl file (I mean, assign textures and all).
...
The obj->bfxm preserves the exported normals, for instance, and in general is cleaner than obj->xmesh->bfxm.

Don't know where you got that idea. My workflow is the same one I layed out in HowTo:Add Ships:
obj->bfxm
bfxm->xmesh(es)
tweak xmesh(es)
xmesh(es)->bfxm

I just have written some short batch files to expedite the process... for instance, obj2xmesh.bat actually goes obj->bfxm->xmesh to avoid the unreliable obj->xmesh conversion.

Thanks for the MTL tips though, I'll try them out. (And I'll add them to the wiki if I figure them out)

GAlex said he might be able to convert the 3ds file properly so I'm going to send it to him before (or while) I try it myself in blender.

[klauss]

Don't know where you got that idea. My workflow is the same one I layed out in HowTo:Add Ships:
obj->bfxm
bfxm->xmesh(es)
tweak xmesh(es)
xmesh(es)->bfxm

It goes well until you do xmesh(es)->bfxm.
Whenever you load xmesh(es), normals get recalculated automatically - kind of autosmoothing. Trouble is, it will smooth out whatever you didn't split, and it will break smoothing groups across texturing seams (didn't do that before some work I did on the obj->bfxm bit - but that bit is needed for Ogre).
I'm trying to figure out a way to overcome that little annoying problem, but it's not exactly easy.
So... the best thing you could do, is skip all those (frankly unnecessary) steps. Most of what you want to do with "tweaking" the xmesh can be done directly in the .mtl file, so you can simply do tweak mtl->obj->bfxm. Simpler... a lot simpler. Aaaand cleaner, because of that little problem I just told you about.
And, if you have something you can't do tweaking the mtl, tell me and I can probably find a (nonstandard) way of conveying that info in the mtl (say... animations could be either detected based on the extension, or specified with ANI_KD, blending mode could also be a keyword, and something similar could be done with alpha testing).

EDIT: Woot! I just had a crazy idea.
Ogre has a 3dstomesh utility to convert from 3DS to Ogre's native .mesh format. Mesher can losslessly (in normal cases) convert from .mesh to .obj. If all else fails, try that utility to do 3ds->ogremesh->obj

BTW: You can also go the 3ds->ogremesh->bfxm route, I think. I'm not sure, though. Can't remember if I finally implemented that one. If you want to try, just tell me and I'll mail you an ogre-enabled binary (that's a big package, though, I'll have to include Ogre's dlls).

[Halleck]

Ugh... well, allright. This is the workflow I learned last year from peteyg and hellcatv (plus my own experiences), I think that was before we had as much MTL support as we do now.

There are some things that can't be done in MTLs though, as far as I know. What about setting the blend mode, the animation file, or the alphamap/alphatest?

Also, what about LODs?

I can do all that stuff easily with xmesh. It's also very easy to go obj->bfxm->xmeshes and then take each xmesh and bring it back to obj to see what submesh it is without screwing around in-game. If it didn't take a minute and half to load the game up it wouldn't be such an issue... each change takes much longer to review than it should, so xmeshes are a nice way to glance over the mesh settings without having to load up the game. Maybe you could make a simple version of SystemExplorer that could be used as a bfxm or mesh preview tool, that would save massive amounts of time.

Alternatively, a bfxm editor program could do the job.

If all else fails, try that utility to do 3ds->ogremesh->obj

I think I'll save that for a last resort.

[klauss]

There are some things that can't be done in MTLs though, as far as I know. What about setting the blend mode, the animation file, or the alphamap/alphatest?

Those in particular are fixable - I'll see about adding commands to set them.

Also, what about LODs?

That one is a bit problematic, I grant you that. It will probably get fixed whenever I address lodding in Ogre (I haven't done that yet, not top priority as I'm waiting for a certain patch they're working on that will transform the way LODs are handled - for the better). In any case, Ogre uses separate files for LOD levels, so I don't really have to support it. In any case... that was the main reason behind the "if you can" bit - if there's something that forces you into xmesh... well... life's a bitch. But the turrets aren't the case
Anyway... I was merely trying to avoid you all the hassle of going through every supported format, and in the way avoid you the hassle of figuring out what went wrong if you stumble upon those bugs. If you're comfortable with xmesh and don't see anything wrong after converting the models, go ahead and keep doing it that way.

[Halleck]

Okie dokie. I've honestly never had problems with xmesh before, though I'm willing to try new methods. Still, xmesh is probably the best format available for editing by hand. For instance, it's a lot easier to remember "texture" than "MAP_KD", at least for me.

I'll try the other methods out, but I don't think that xmesh is the problem here. In the original wings files I looked at, the UV mappings seemed a bit chaotic. I couldn't really tell without seeing the texture, though. I suppose I could get the texture into wings (with some effort.) In fact, I think I'll try that first thing. Seems like a good acid test to me.

[Halleck]

I wasn't able to get the textures to apply at all in wings, but I did go back to my original project and had it draw the uv mapping to a file. I then colorized it and composited it with the appropriate texture using GIMP. Here are two such composite images, the railgun and missile respectively:


It can be clearly seen that some of the mappings are just screwed up. Again, this is in the wings file made from the obj made from the original 3ds file. So the problem is either 3ds->obj (likely) or obj->wings (not likely, I've never had trouble with this before.)