Author Topic: Creating efficient models, a coders point of view... (very long post)  (Read 84629 times)

0 Members and 1 Guest are viewing this topic.

Offline Flaser

  • 210
  • man/fish warsie
Re: Creating efficient models, a coders point of v
taylor, what's your take on detail-boxes?

When and how should they be used? What's the efficient texture usage with them?
Omniscaper already made a huge impact with his Deathstar, however AFAIK few modellers truely know what they are and how to use them.

On a sidenote: Shinemaps are a lot more than 8-bit black and white images!
Almost none of our models (except the Rahu, Shivan gasminer) use them to their true potnetial.
Bobbau designed something that's way ahead it's time it can:
-Convey the 'texture' of the surface: rough, smooth, jagged, ect // Just apply the apropiate noise maps to the area
-Convey the shine 'color' of the surface. Once again brighting/darkening the main map can work, but there's so much more to this. Ever seen the Arcadia with the blue tint? ....brass, copper, lead, silver, gold, ruby, emerald....all are possible if you're willing to experiment with shine colors different from the main texture.
"I was going to become a speed dealer. If one stupid fairytale turns out to be total nonsense, what does the young man do? If you answered, “Wake up and face reality,” you don’t remember what it was like being a young man. You just go to the next entry in the catalogue of lies you can use to destroy your life." - John Dolan

 

Offline Galemp

  • Actual father of Samus
  • Moderator
  • 212
  • Ask me about GORT!
    • Steam
    • User page on the FreeSpace Wiki
Re: Creating efficient models, a coders point of v
IMHO the best approach would be if it would be possible to set which LOD of the given model is to be used.
Now that's a damn good idea.  It could be added to the ships.tbl entry and if it's specified it will use that LOD number of the original model rather than the default.  I'll see if I can't add that sometime next week, or WMCoolmon can do it if he has time.
We already have the field $POF target file: that can point to an external file. Could we extend this to have the options LOD0, LOD1, LOD2, or LOD3 to force a certain LOD? I'd really like to see bombs use LOD0 since their target view is often bigger than the 'real' view, and there are some big and detailed models whose target view could use LOD2 instead of LOD1.
"Anyone can do any amount of work, provided it isn't the work he's supposed to be doing at that moment." -- Robert Benchley

Members I've personally met: RedStreblo, Goober5000, Sandwich, Splinter, Su-tehp, Hippo, CP5670, Terran Emperor, Karajorma, Dekker, McCall, Admiral Wolf, mxlm, RedSniper, Stealth, Black Wolf...

 

Offline taylor

  • Super SCP/Linux Guru
  • 212
    • http://www.icculus.org/~taylor
Re: Creating efficient models, a coders point of v
taylor, what's your take on detail-boxes?

When and how should they be used? What's the efficient texture usage with them?
Omniscaper already made a huge impact with his Deathstar, however AFAIK few modellers truely know what they are and how to use them.
Don't really have a take on them since I don't much about them either.  The basic exturing rules should apply the same way though.  How and when they should be used is a question better directed to someone who has used them before, or more appropriately, Bobboau.

On a sidenote: Shinemaps are a lot more than 8-bit black and white images!
<--snip-->
Agreed.  And if they are going to be used I'd much rather have them really take advantage of what they can do.  Just making things shiny is rather boring.  I remember when Lightspeed was re-texturing the old models and just how awesome some of them were with the shinemaps (like the Rahu).  If I'm going to waste memory on an extra set of maps then that's how I want to do it. :)

With nice ones like that is where you start to have the differing size problems that DaBrain hit on.  That's just another situation where the content can dictate what the final textures are going to be.  But even so, if using one set of textures (base/glow/shine) for multiple LODs you will very quickly and very easily save any extra memory that would have been used.  And though I didn't really touch on this in my original post, if reusing textures for multiple LODs then LOD switching is not only faster it's also much more seamless since you won't notice the geometry change as much as a texture change.

We already have the field $POF target file: that can point to an external file. Could we extend this to have the options LOD0, LOD1, LOD2, or LOD3 to force a certain LOD? I'd really like to see bombs use LOD0 since their target view is often bigger than the 'real' view, and there are some big and detailed models whose target view could use LOD2 instead of LOD1.
Yeah, that's what I want to add/change.  Basically there would be a $POF target LOD: and you would just give a LOD number.  The targetbox will still use LOD1 by default but check this entry if found and update the model detail level before rendering.  The would work instead of $POF target file: since if you created a separate file then you would probably only make one LOD anyway, but both options would still be supported.  It would take about 10 minutes to add and make usable the new option but I don't really have 10 minutes for that today. :sigh:

 

Offline taylor

  • Super SCP/Linux Guru
  • 212
    • http://www.icculus.org/~taylor
Re: Creating efficient models, a coders point of v
Yeah, that's what I want to add/change.  Basically there would be a $POF target LOD: and you would just give a LOD number.  The targetbox will still use LOD1 by default but check this entry if found and update the model detail level before rendering.  The would work instead of $POF target file: since if you created a separate file then you would probably only make one LOD anyway, but both options would still be supported.  It would take about 10 minutes to add and make usable the new option but I don't really have 10 minutes for that today. :sigh:
Ok, it's in CVS now.  In ships.tbl $POF target LOD: goes before $Detail distance:.  In weapons.tbl it goes before $External Model File:.  Values are 0 to whatever number of LODs the POF has.  If you use a LOD number higher than is in the POF then it will get capped to the next lowest LOD number.  This will specify what LOD is used to render the ship (the ships.tbl entry) in for the targetbox, what LOD to use for a weapon (the weapons.tbl entry), and if using weapon view then it determines the LOD of the ship (the ships.tbl entry again) that the bomb/missile is seeking.

And looking at the code I did find where it's using an offset for the LOD that gets shown in both the lab and the targetbox.  I'm not sure why this change was made, but based on the comment that person didn't really understand/consider what's going on there.  So, now the lab and the targetbox will really use the correct LOD.  It was down by one so LOD0 was trying to use -1 and getting set to 0, LOD1 was trying to use 0, LOD2 was 1, etc.  Basically every LOD shown was actually one higher than it should have been in those two places (but not the normal game).  Galemp called it and I didn't believe it at first, but I've now proven myself wrong. :)   That incorrect LOD handling change with locked detail levels was made 2 years ago btw.

This should show up in the next available CVS build.

 

Offline StratComm

  • The POFressor
  • 212
  • Cameron Crazy
    • http://www.geocities.com/cek_83/index.html
Re: Creating efficient models, a coders point of v
I'd been wondering why that happened.  I suspected it was to force LOD0 models to get rendered on the HUD, which would have made sense 2 years ago before all of the HTL models started appearing, but I'm glad it's fixed.
who needs a signature? ;)
It's not much of an excuse for a website, but my stuff can be found here

"Holding the last thread on a page comes with an inherent danger, especially when you are edit-happy with your posts.  For you can easily continue editing in points without ever noticing that someone else could have refuted them." ~Me, on my posting behavior

Last edited by StratComm on 08-23-2027 at 08:34 PM

 

Offline taylor

  • Super SCP/Linux Guru
  • 212
    • http://www.icculus.org/~taylor
Re: Creating efficient models, a coders point of v
I'd been wondering why that happened.  I suspected it was to force LOD0 models to get rendered on the HUD, which would have made sense 2 years ago before all of the HTL models started appearing, but I'm glad it's fixed.
It was done to (according to the comment) stop swapping LOD textures in and out of memory.  The problem with that is they are all loaded already and though they might have to go in and out of API memory again, any possible texture speed increase is completely reversed by the extra cycles and memory needed to render a higher poly count and higher texture quality model.  What the change was trying to prevent just went against how the code actually works.  The proper fix to get LOD0 models to render on the HUD is just a very small, one line change to the targetbox code, though that wasn't what was done.

But it is correctly fixed now and you will get the option of using any LOD you wish for the targetbox on a per ship basis.  Plus it doesn't have the negative impact on the lab functionality (ie. you never got to see the final LOD since it used the one before it) that the previous change was making.

 

Offline Galemp

  • Actual father of Samus
  • Moderator
  • 212
  • Ask me about GORT!
    • Steam
    • User page on the FreeSpace Wiki
Re: Creating efficient models, a coders point of v
Hallelujah!
"Anyone can do any amount of work, provided it isn't the work he's supposed to be doing at that moment." -- Robert Benchley

Members I've personally met: RedStreblo, Goober5000, Sandwich, Splinter, Su-tehp, Hippo, CP5670, Terran Emperor, Karajorma, Dekker, McCall, Admiral Wolf, mxlm, RedSniper, Stealth, Black Wolf...

 

Offline WMCoolmon

  • Purveyor of space crack
  • 213
Re: Creating efficient models, a coders point of v
And looking at the code I did find where it's using an offset for the LOD that gets shown in both the lab and the targetbox.  I'm not sure why this change was made, but based on the comment that person didn't really understand/consider what's going on there.  So, now the lab and the targetbox will really use the correct LOD.  It was down by one so LOD0 was trying to use -1 and getting set to 0, LOD1 was trying to use 0, LOD2 was 1, etc.  Basically every LOD shown was actually one higher than it should have been in those two places (but not the normal game).  Galemp called it and I didn't believe it at first, but I've now proven myself wrong. :)   That incorrect LOD handling change with locked detail levels was made 2 years ago btw.

w00t :)
-C

 

Offline FireCrack

  • 210
  • meh...
Re: Creating efficient models, a coders point of v
I'd also like to know more about when to use detail boxes.

On my ursa i'm thinking of making a single detail box that contains all the grebles for ultra-close-in viewing, wich would could the model overall would use one less lod because otherwise lod 1 and lod 2 would be the same except with and without grebles.
actualy, mabye not.
"When ink and pen in hands of men Inscribe your form, bipedal P They draw an altar on which God has slaughtered all stability, no eyes could ever soak in all the places you anoint, and yet to see you all at once we only need the point. Flirting with infinity, your geometric progeny that fit inside you oh so tight with triangles that feel so right."
3.141592653589793238462643383279502884197169399375105820974944 59230781640628620899862803482534211706...
"Your ever-constant homily says flaw is discipline, the patron saint of imperfection frees us from our sin. And if our transcendental lift shall find a final floor, then Man will know the death of God where wonder was before."

 

Offline StratComm

  • The POFressor
  • 212
  • Cameron Crazy
    • http://www.geocities.com/cek_83/index.html
Re: Creating efficient models, a coders point of v
There's no difference graphically between that and an extra LOD (I'm not sure that detail boxes are useful on fighters, except maybe for pilot models) and you actually hurt performance when you're up close because then there's another submodel to render and another submodel rendering call that has to be made.  Detail boxes make sense for detailing parts of a larger ship where only one or two particular parts will be visible close enough for any scrutiny at any given time; for a fighter (and using a single box) it's not the same win.
who needs a signature? ;)
It's not much of an excuse for a website, but my stuff can be found here

"Holding the last thread on a page comes with an inherent danger, especially when you are edit-happy with your posts.  For you can easily continue editing in points without ever noticing that someone else could have refuted them." ~Me, on my posting behavior

Last edited by StratComm on 08-23-2027 at 08:34 PM

 
Re: Creating efficient models, a coders point of view... (very long post)
Thanks for the advice. However I am unable to save in DDS for some odd reason. I have that Nvidia thing to use it but when I go to the save menu the save button is greyed out.
I have created a masterpiece.

 

Offline taylor

  • Super SCP/Linux Guru
  • 212
    • http://www.icculus.org/~taylor
Re: Creating efficient models, a coders point of view... (very long post)
Thanks for the advice. However I am unable to save in DDS for some odd reason. I have that Nvidia thing to use it but when I go to the save menu the save button is greyed out.
You mean you are using the Photoshop plugin or something else?  Is the image power-of-2 and 24 or 32-bit and a supported read format (BMP, TGA, TIF, plus a couple of others, may be a restriction to save)?

 
Re: Creating efficient models, a coders point of view... (very long post)
Yes its a photoshop plugin. I'm not sure about power of 2. Its a 32 bit TGA 800x800 texture.
I have created a masterpiece.

 

Offline karajorma

  • King Louie - Jungle VIP
  • Administrator
  • 214
    • Karajorma's Freespace FAQ
Re: Creating efficient models, a coders point of v
Try it as 1024x1024 or 512x512 and see if it works.
Karajorma's Freespace FAQ. It's almost like asking me yourself.

[ Diaspora ] - [ Seeds Of Rebellion ] - [ Mind Games ]

 

Offline taylor

  • Super SCP/Linux Guru
  • 212
    • http://www.icculus.org/~taylor
Re: Creating efficient models, a coders point of view... (very long post)
I keep waiting for CVS to get working again before I post this but I guess I'll go ahead and give everyone the heads up...

Full support for non-compressed DDS mipmaps will hit CVS as soon as the server starts working again.  The compressed DDS mipmap handling has been tweaked a little as well.  Also hitting CVS at the same time is support for bilinear and trilinear filtering (since those two things work with mipmaps).  Just add "TextureFilter=1" to the registry (for Windows, a DWORD value) or ini file (for Linux and OSX) to enable trilinear filtering.  The default ("TextureFilter=0") is bilinear whenever an image has mipmap levels.  These settings don't have any affect unless the texture is properly mipmaped though so this is just some enticement for the map makers out there. ;)

This also makes the recent anisotropic filter update for OGL actually work worth a crap now, since it's basically the quality of mipmap filtering.  Anisotropic filtering will sharpen up textures that have been hit by bilinear or trilinear filtering.  For those that didn't catch that registry setting before, it's "OGL_AnisotropicFilter", which is a string value that is set from "1.0" to what ever your video card can handle.  The max value is capped to what the video card supports to feel free to do "99.0" or something to always get the max value.  Note that "1.0" (the default value) actually turns the anisotropic filter off so you need a value of at least "2.0" to enable it.

All of this is OGL only for the moment of course, but eventually someone will modify the D3D code to have the same support.

 
Re: Creating efficient models, a coders point of v
Kudos, I think it was about time somebody tackled this subject.

I really love some of the artwork that you guys create for Freespace but every time I turn my fighter and bring a new Orion or a science vessel (I think this has since been resolved though) into view my framerate takes a massive hit. I consider my computer to be fairly powerful....


I only have one thing to say: Fenris/Leviathan.
"Do you plunder?"
"I have been known to plunder..."
"I refer ye t' darkstar one, one o' th' newer big budget spacers - it's lack o' variety were bein' insultin', an' th' mechanics weren't polished at all.  Every time a title like wot comes out, it pushes th' return o' th' space shooter genre further down th' sea." - Talk like a pirate day '09
"Hope for the best, expect the worst." -Heinlein

 

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
Re: Creating efficient models, a coders point of view... (very long post)
freespace wont use textures bigger than 2048^2? why do i just find this out now? the biggest texture ive done so far would be the 4096^2 texture i did for the ragnarok/valhalla class corvettes and the planned carrier varient as well. yes the texture is huge but the 3 ships all use the same texture and only one that texture, where the old versions used 4 textures. the ships are ~ 750 meters long and the textures look to damn good and if there getting redced to 1/4 the pixel count they once had then thats pretty good texturing. ive been giving many ships in nukemod the htl makeover, doing texture merges and so on also while adding detail and cockpits to the models. ive been using the rules that were established by bob way back when htl was just implemented, which were esentally use fewer textures (my mod now uses 50% fewer textures), and no mipmaps (as back then freespace didnt use them and generated their own), and the others regaurding lods which i still havent made yet (i plan to, eventually, when im really bored). i like to use big textures for future proofing my models, just cause the game cant handel a certain texture doesnt mean you shouldnt make it that big, just so long as you release with a smaller version. originally i was going to offer the gargantuan textures as a seprate download but sence freespace doesnt support them i might as well forgo the hassel. your info is certainly helpfull and cleared up a few questions i had regaurding mipmaping and lod textures. the only thing that concerns me is that the engine isnt using the full texture for the ragnarok. i figured my 256 meg video card would handel the 8 meg texture just fine (thats how big a 4096^2 dxt1 is). i didnt know there was a cap in the software.
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN

 

Offline taylor

  • Super SCP/Linux Guru
  • 212
    • http://www.icculus.org/~taylor
Re: Creating efficient models, a coders point of view... (very long post)
freespace wont use textures bigger than 2048^2? why do i just find this out now?
It has nothing to do with Freespace, it's a video card thing.  And it's not that it won't use larger than 2048, it's that any texture larger will automatically get resized to 2048 by the video card before using it.  Which basically means that you have forced a 4096 on everyone and you get nothing for it but wasted memory and slower performance.  Most video cards have a max texture size of 2048x2048 and anything larger than that is just wasting everyones time.  My video card supports 4096x4096 but I will banish you to the deepest depths of Hell if you use a 4096 for anything but huge installations, and even then it would be accepted under protest since 99% of the time that the texture is on screen it's being minimized and distorted.

just cause the game cant handel a certain texture doesnt mean you shouldnt make it that big
Just because the ocean lies at the base of that 300 meter cliff doesn't mean that you should jump off the damn thing and go for a swim.

As I have said already it's about creating efficient textures.  That doesn't necessarily mean fewer textures.  You want to try and use fewer textures per ship but you are seriously misunderstanding that statement if making one massive texture and using it for multiple ships is how you do it.  Using fewer textures overall doesn't help anyone if the textures just end up being larger and the video card has to do more work to use them.  Fewer textures only means reducing the number of textures a single ship must be rendered with.

 

Offline WMCoolmon

  • Purveyor of space crack
  • 213
Re: Creating efficient models, a coders point of view... (very long post)
I dion't really mind as long as it's not causing me significant slowdowns.
-C

 

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
Re: Creating efficient models, a coders point of v
i think you interpreted what i said as a complaint rather than a question. my video card is a 256 meg card, and it can handel theese big textures, so does that mean its getting resized anyway? i want to know so i can make a comparison to see for my self what would be better. i have no intention of releasing the mod with that big texture, mainly because i cant expect everyone to have as much texture memory as i do. 8 megs is alot, and thats not including shine and glow maps. and on a 64 meg card it will be completely unplayable. recently i made a bunch of new effects and i was contemplating using tgas cause they looked slightly better than dxt1s. bat after compairing the tga files with the dxt1s i dumped the tgas. it was too much a cost for such little gain. my reasoning for making big textures is that i might want to use the model for something else down the line. i can imagine several years from now people will comment on how low res these 2048^2 maps are. that is why i make them that big. seeing as the textures are rendered in photoshop from literally hundreds of layers (now hats a big image file, half a gig), it doesnt cost any detail to resize them in photoshop. im sure [v] did there maps at a much bigger scale, and then scaled them down for the final product.
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN