[taylor]

I hate bumping this thread for something so stupid, but I don't want to start a new thread to announce this, and it is sort of relevant...

I've been working on improved texture replacement functionality.  It originally started out as a performance tweak, but since I had always wanted to fix the short-comings with that code, I just took it all the way.  The current texture replacement functionality had serveral issues: 1) it only worked for the base maps, it couldn't change glow/spec/normal maps at all, 2) it wasn't as efficient as it could have been, 3) it's application was limited to per-mission use.

Issues 1 & 2 were addressed in the same manner.  The code now keeps track of the full set of textures, a combination of the originals and any replacements, and can quickly and easily pass those around to be rendered.  The same texture loading function works for these extra texture sets, so it will easily handle a new base map and automatically load up the respective glow/spec/normal map to go with it.  This also works with "-amb" and "-trans" textures, allowing you to quickly and easily get the same level of control that you would have by editing the POF itself.

Issue 3 was solved by adding an extra level of texture replacement, through ships.tbl.  So say that you have the Fenris and Leviathan, both of which are the same model, but the hi-poly versions are different POFs in order to get different textures.  With texture replacement you can use the single POF and just change out the textures by default every time the ship is used.  This works in mission as well as in the lab and techroom.  It's essentially the same as using two POFs, except you save a good bit of system and video card memory by not having to load up an extra POF.  The normal mission specific texture replacement works on top of this, so you still have full control of how the model will be presented in-mission.

The ships.tbl level texture replacement is mainly just to help out mods which already have multiple tbl entries, with the same basic POF, just to get a different set of default textures.  The new texture replacement code will now allow you to just have the one POF, and use texture replacement to change the default textures for those ships.  I already use this myself for the Fenris, Leviathan and the Cain, Lilith ships, allowing the use of the same POF but still getting the different texture sets that we are all used to.  The texture replacement usage is the same in ships.tbl as in missions.  So just make use of the same "$Texture Replace:" setup than you are used to, putting it after the POF filename specification in the ship tbl entry.

This new code will start showing up in builds starting next week, and will be included with 3.6.10.  Hopefully it will be of some help to various modders and model makers out there.

[Vasudan Admiral]

Oooh, that sounds pretty cool.

Couple of questions:
1) Can/will we be able to change textures mid-mission via SEXP?
I'm under the impression we can't yet, but I reckon this would be the best way to handle custom cloaking devices and the like.

2) If you only wanted to change from one glowmap to another, would that be possible without creating a second base texture to switch to?
I've had an idea running around my head for a while to try and give some ships a cooler death sequence. I made an experimental render-vid in 3ds Max a while back which gets the idea across well enough: http://sectorgame.com/ti-file-dump/VasudanAdmiral/Videos/LightFlickker.avi

Obviously mid-mission texture replacement isn't the proper way to go about it if it was meant as a game-wide kinda feature, but it's a step in the right direction and would allow us to test it in-game.

3) I don't think I've heard of the "-amb" or "-trans" tags before - how do they work?

4) So what would the table entry actually be?
At a total guess, "$Texture Replace: (Fenris-HTL, Levvy-HTL)" ?

[taylor]

1) Can/will we be able to change textures mid-mission via SEXP?

It can't change via SEXP at the moment, but the new replacement framework does make such a thing possible.  And it wouldn't be that much work to code it in either.  I'm probably not going to do that myself unless there is a big enough push for it from enough people, but I suspect that Goober or karajorma could take care of it pretty easily with just a quick chat with me about how all of the new code works.

2) If you only wanted to change from one glowmap to another, would that be possible without creating a second base texture to switch to?

No, it's linked to the base filename, so you would have to change the base texture as well (and spec, and normal/bump).  That sucks, I know, but there are probably better ways we could add in the effect that you want anyway.  Something like a "death glow", which could either be another map entirely, or just a normal glow map which is animated but only shows one frame unless the ship is dying.  I'm not really sure though, this is really something that we could/should probably add a new sort of effect system for.  Then it could take care of death/birth animations and all sorts of in-between stuff like cloaking.  Something to add to the todo list I guess.

3) I don't think I've heard of the "-amb" or "-trans" tags before - how do they work?

"-trans" will render a map as additive blended.  The same way that the game blends most effects (where black == transparent) it could also render that particular model texture.  It has limited uses, and I don't pretend to really know what all could be done with it, but I'm sure that some people could do some creative things.  I know that DaBrain is using it for at least one ship texture for SoL.  It that case it allows for a transparent glow that will blend properly with anything behind and in front of the model/texture.

As far as "-amb" goes, it's basically the same as rendering without lighting, but per texture rather than for the model as a whole.  I'm not sure that the option actually does anything different in HTL mode though.  But I don't think that there is a reason for that other than the fact that support for it has just never been added to the HTL render path.

4) So what would the table entry actually be?

For the Levy, it would just be something as simple as this:

Code: [Select]

$POF file:        cruiser01.pof
$Texture Replace:
+old: fenris-htl
+new: levy-htl
Here is a the tbm that I've been using for the Levy and Lilith: mv_models-shp.tbm
Obviously you need a new build, which isn't out yet, for that tbm to work, but it should give you an idea of what changes would be needed.

[Vasudan Admiral]

It can't change via SEXP at the moment, but the new replacement framework does make such a thing possible.  And it wouldn't be that much work to code it in either.  I'm probably not going to do that myself unless there is a big enough push for it from enough people, but I suspect that Goober or karajorma could take care of it pretty easily with just a quick chat with me about how all of the new code works.

That's great news.
I can tell you for sure that TI would use it a lot. In fact I have a number of fairly detailed special effect sequences or tricks I typed up a year ago when I thought mid-mission texture replacement was possible.
Things like force-field effects (that need to be easily and visibly switched on or off), turret model glowmaps that light up when the turret is preparing to fire, cloak effects that have a particular look (ie, you define how they look come on or off via a short animated texture rather than using a pre-defined cloak function), creating big damage effects in special effect sequences, changing glowmap effects when a ship goes into attack mode, and a couple of others I've probably forgotten.

Believe me, it'd be a very powerful little feature.

No, it's linked to the base filename, so you would have to change the base texture as well (and spec, and normal/bump).  That sucks, I know, but there are probably better ways we could add in the effect that you want anyway.  Something like a "death glow", which could either be another map entirely, or just a normal glow map which is animated but only shows one frame unless the ship is dying.  I'm not really sure though, this is really something that we could/should probably add a new sort of effect system for.  Then it could take care of death/birth animations and all sorts of in-between stuff like cloaking.  Something to add to the todo list I guess.

Something like that was what I was thinking would be perfect if it were to be a game-wide feature rather than just the 'idea' it is now.
That said however, I don't think an entire new effect system is the only way to do this sorta stuff. I mean, if we could change textures mid-mission, I think this would already be possible to do via the scripting system - same sorta thing as Wanderer's awesome little flashy deaths script, except set it to switch ships over to their death animation glowmaps if they have them as they're beginning to go pop.

"-trans" will render a map as additive blended.  The same way that the game blends most effects (where black == transparent) it could also render that particular model texture.  It has limited uses, and I don't pretend to really know what all could be done with it, but I'm sure that some people could do some creative things.  I know that DaBrain is using it for at least one ship texture for SoL.  It that case it allows for a transparent glow that will blend properly with anything behind and in front of the model/texture.

Ah - another cool feature that snuck past me.
So is this just a tag you add to the base map or is it a separate texture? Also, is the end result much different from setting a base texture to be transparent via the alpha channel? I'm a bit unclear there.

Thanks again for all these answers btw. Really appreciate it.

[taylor]

Something like that was what I was thinking would be perfect if it were to be a game-wide feature rather than just the 'idea' it is now.
That said however, I don't think an entire new effect system is the only way to do this sorta stuff. I mean, if we could change textures mid-mission, I think this would already be possible to do via the scripting system - same sorta thing as Wanderer's awesome little flashy deaths script, except set it to switch ships over to their death animation glowmaps if they have them as they're beginning to go pop.

A new effect system wouldn't be required to do what you want, obviously, but it would make the task considerably easier.  A new effect system would really just be seriously upgraded shipfx code, something that you can have far greater control over.  Things like warp in/out, cloaking, death sequences, and other large scale type of effects would run through there.  You could do things like the Shadow shimmer for TBP for instance, or a real BSG style FTL thing.  Such effects could probably be done now using scripting and the particle system, but the particle system just really isn't suited for such things.  A new effects system would also allow far easier tie-in for shaders as well, giving you the ability to bring a far more detailed and customized effect.

So is this just a tag you add to the base map or is it a separate texture? Also, is the end result much different from setting a base texture to be transparent via the alpha channel? I'm a bit unclear there.

It is just what you add to the base map.  So if your texture is normally "fenris-htl" then rename it to "fenris-htl-trans" for both the filename and the name that is referenced in the POF.  It will then render as transparent.  Make sure to change glow/spec map names as well, so that they can still load.  This doesn't necessarily preclude the use of real alpha though.  In the effect that SoL is using, they have a small black base texture (which is -trans, and rendered transparent) with a glow map which makes use of real alpha.  It's a really neat effect.

[Vasudan Admiral]

Well.... that sounds most intriguing. 
Are there any current plans for how such a system would work at the modders level?
Ie, would stuff be defined in a separate table or the ships table on a per ship basis, and what sorta stuff would it give control over that can't be done or can't easily/efficiently be done at the moment? Particles/lightning/explosions sorta thing?

(Sorry, more questions - but you've gotten me interested now. )

[Goober5000]

1) Can/will we be able to change textures mid-mission via SEXP?
I'm under the impression we can't yet, but I reckon this would be the best way to handle custom cloaking devices and the like.

That's an excellent optimization idea.  You can already cloak/decloak ships by using change-ship-class for models with animated textures, but changing the map would be even better.  Ask the WCSaga guys for the cloaktest zip I sent them awhile back.  (I don't think I have it myself anymore.)

[Vasudan Admiral]

I remember that actually - back when I saw it I thought it was a bit of an odd way to go about it though, since I still thought the texture replacement worked mid mission.

It is a clever way to do it with what we have now though.

[taylor]

Are there any current plans for how such a system would work at the modders level?
Ie, would stuff be defined in a separate table or the ships table on a per ship basis, and what sorta stuff would it give control over that can't be done or can't easily/efficiently be done at the moment? Particles/lightning/explosions sorta thing?

There aren't really any current plans (detailed anyway) for the new system, it's just something that we seriously need to work on at some point in the not too distant future.  The idea would be to make it all more moddable, both from a tbl level and from a scripting level.  We will at the very least need a good tie-in interface, at the tbl level, for shaders.  If that is going to be done half-way decently then it needs to be done as the ground work an improved effects system for larger scale things.  The particle system needs to then be scaled back for smaller and more speciallized effects (the two systems are mutually exclusive in principle from a design/optimization point of view).

Whether or not this will all be provided though existing tbls (other than the shader definition files themselves) or whether an additional tbl will be introduced, it totally up in the air.  Obviously the intent will be to do as much as possible with the existing tbls though.

[Inquisitor]

Not sure if anyone has said this before, taylor, but that is all excellent advice regardless of which game engine you use. If people perfect those skills here, the principles are relevant to other game engines, which in turn makes for a real skill that could be valuable to that artist later down the line.

Anyway, back to your fetaure discussion

[TrashMan]

Great thread 

I should really make DDS version of my textures...sigh...

[pecenipicek]

Necroing this for a quick question...


Considering the first post and advances in both the rendering resolutions and PC internals, giving us more power for $$$, what would be the general.. well, reccomendations on texture size and ship polycounts?

[KewlToyZ]

I am using Rhino as my main modeling program to export as 3DS or OBJ, then 3D Exploration for doing my export to COB, then PCS2 to create a POF.
I have MAX 4 at my disposal but find it way too clumsy and over complicated as a modeling platform.
I have a question concerning overall capital ship construction.
When I create groups of objects:
Turrets:
do I group the cannon arm components, then group the cannon arms to the base of the turret?
create a separate layer and group for each turret?
Then group the turrets as one large group, then group them to the main hull group of poly's?
Do I group each level of the model details in any specific order to be read?

Do I name the layers, objects, and groups with the Detail-01 , Detail-02, Turret-01, Turret-02, etc.. tags by level of detail?
Or do I have more freedom in naming my objects, Groups, Layers, etc...?

[Vasudan Admiral]

To be honest it probably won't matter at all what you call your objects and groups - you'll most likely lose them when going through 3d exploration.
 
This is what a healthy hierarchy will look like in TS:

(The names of the lights and meshes are not important - the names of the objects are)

3d exploration won't keep those lights intact, meaning that you'll often find your turret arms will merge with the turret base as one object, and single part turrets will merge with the hull object, because object groups can only be formed with two or more objects.

You might be able to get around this though, by using dummy objects - and by that I mean just really tiny tetrahedrons placed inside other geometry to create the object groups. Then you might be able to set it up to export from 3d exploration like on the right hand side of this:




Oh, and finally - have a look at this thread and also check to see if you are able to export Collada .DAE objects from Rhino. If so, then your conversion life is probably going to become a whole lot easier soon.

[KewlToyZ]

Awesome post sir, I truly thank you! 

[chief1983]

VA, I'd say sticky this after a post like that but it already is.  Hope everyone notices that who needs to.  Maybe it should be split and stickied somewhere?  Or put on the wiki?

[Vasudan Admiral]

Well the collada implementation should soon be doing away with the need to so clearly understand the TS hierarchy I'm hoping.

And to be honest my description there is kinda all over the place. I really should write up a better one for the wiki sometime.

[Bryan See]

[q], anisotropic filtering level just became a registry option for instance[/q]

What's the flag? I would like to try this out.

It's a string value, "OGL_AnisotroicFilter", but it only takes numbers (a float value).  Minimum value is 1.0, which is to not enable the filter, max value is determined by the video card (will likely be 16.0 on current cards).  It will cap the value if you go out of that range.  Also, if using a debug build, you can change the setting in game by bringing up the debug console with "Shift-Enter" and using the "ogl_anisotropy" command.  Use "help ogl_anisotropy" to get a general idea of it, "ogl_anisotropy" with no options will reset to the default/registry value, "ogl_anisotropy x" will set the filter to "x" value.  The default value is 1.0.

The anisotropic filter did work before but not properly, and it was always set to the max.

What about DirectX's anisotropic filter? Did it still not work properly as OpenGL's equilavent?

And also, as you never heard before, the geometry instancing is a practice of rendering multiple copies of the same model in a scene at once. I believed it may be used as ships, asteroids, and other objects. It is supported starting from Direct3D version 9 which will be implemented in future releases. 

[Sandwich]

So lemme get this straight: you bumped a thread that's been inactive for nearly a year, to respond to a post that was from over 3 years ago? You're lucky your post is relevant...

[chief1983]

Whoa whoa whoa, hold on.  Nevermind that this was some pretty big necro, it's also his first post, so maybe he's been lurking for a while and just wants to set the record for most beams caused by one post.  I dunno.  But what do you mean D3D9 will be implemented in future releases?  Of what, FSO?  Are you volunteering to fix FSO's D3D support or something?  Also, did you go to UMR?  I knew of a Bryan See but I'm not sure how spelled his name.