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

0 Members and 1 Guest are viewing this topic.

Offline chief1983

  • Still lacks a custom title
  • 212
  • ⬇️⬆️⬅️⬅️🅰➡️⬇️
    • Minecraft
    • Skype
    • Steam
    • Twitter
    • Fate of the Galaxy
Re: Creating efficient models, a coders point of view... (very long post)
I have to admit, it's strange that you seem so eager to join the SCP.  Normally, people just join the community, contribute some stuff, hang around, etc.

Anyway, you need to provide us the code you've changed so we can see what's going on with it.  If you're expecting to put some sort of stipulation on it, like if you become part of the team you'll provide the code, I'm sorry but that's not how it works around here.  We're really not that desparate for it in the first place.  People become part of the 'the team' when they act like part of 'the team'.  This isn't the NFL.

So if you really just want to help out, we need to see the code so we can check it for any pitfalls it might have.  As far as I can tell it's not actually functioning right now.  This probably sounds like exactly what Zacam said but I still felt the need to say it my way :)

To clarify, Zacam also meant that by default, in all the project files the NO_DIRECT3D preprocessor define has been enabled, and would have to be removed in order to compile Direct3d builds.  Otherwise it wouldn't have any effect.  As far as I can tell, these builds were compiled with that define enabled.  Again, that's why we need to see the actual code, since it appears something is going quite wrong at this point.
Fate of the Galaxy - Now Hiring!  Apply within | Diaspora | SCP Home | Collada Importer for PCS2
Karajorma's 'How to report bugs' | Mantis
#freespace | #scp-swc | #diaspora | #SCP | #hard-light on EsperNet

"You may not sell or otherwise commercially exploit the source or things you created based on the source." -- Excerpt from FSO license, for reference

Nuclear1:  Jesus Christ zack you're a little too hamyurger for HLP right now...
iamzack:  i dont have hamynerge i just want ptatoc hips D:
redsniper:  Platonic hips?!
iamzack:  lays

 

Offline Bryan See

  • Has anyone really been far as decided to use even go want to do look more like?
  • 210
  • Trying to redeem, but under Tiger Parents
    • Skype
    • Steam
    • Twitter
Re: Creating efficient models, a coders point of view... (very long post)
I see the problem, and I have to remove the NO_DIRECT3D preprocessor define which has been enabled, since I'm a new maintainer for D3D support.

Anyway, are there any issues related to efficient model rendering that I would like to fix?
Bryan See - My FreeSpace Wiki User Page (Talk, Contributions)

Full Projects:
Shattered Stars

Campaigns:
Lost in the Mist - Cyrene vs. Psamtik
FreeSpace: Reunited

Ships:
GTS Hygeia, GTT Argo, SC Raguel

Tools:
FSO TC/Game template

I've been under attack by Tiger Parents like Jennifer Pan...

 

Offline pecenipicek

  • Roast Chicken
  • 211
  • Powered by copious amounts of coffee and nicotine
    • Minecraft
    • Skype
    • Steam
    • Twitter
    • PeceniPicek's own deviantart page
Re: Creating efficient models, a coders point of view... (very long post)
I see the problem, and I have to remove the NO_DIRECT3D preprocessor define which has been enabled, since I'm a new maintainer for D3D support.

Anyway, are there any issues related to efficient model rendering that I would like to fix?
why dont you post your diff files first.
Skype: vrganjko
Ho, ho, ho, to the bottle I go
to heal my heart and drown my woe!
Rain may fall and wind may blow,
and many miles be still to go,
but under a tall tree I will lie!

The Apocalypse Project needs YOU! - recruiting info thread.

 

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 view... (very long post)
:necro:

If you even CAN necro a sticky... Can we have a 2015 update to the 2011 addendum?

I've learned that it's perfectly okay to have a unique texture for each subobject in the model. What should specifically be avoided is using multiple textures for one subobject. That means it's okay to use a shared texture for turrets, or a debris texture for debris chunks/destroyed submodels, or to put all your subobjects (turrets, radar dishes, rotating submodels, detail-boxed greebles) on a separate texture from the main hull.

With modern models it seems low-poly optimization is something of a lost art. (Kids these days, when I was your age we had 800 polies for a juggernaut, grumble grumble.) What kind of polycounts should we be shooting for, for each size of ship? I've seen fighters with many thousands of polies that do little more than slow down the wireframe 3D Ship Select animation, with fine details that should really be normal-mapped; but practically, how much difference does this make? Likewise, I'm working on a cruiser-sized ship now that can be optimized to less than half its current polycount with no loss of detail, but how important is it to actually put in the work? Is geometry processing so computationally cheap that I don't have to bother?

How does the engine handle non-manifold geometry nowadays? If I have intersecting polies, do lighting and collision detection work properly? Can I use intersecting geometry, such as uncapped tubes between hull elements, without having to boolean solids and clean up the joins?

Are quads recommended, acceptable, or discouraged?

Thanks for bringing me up to date.
"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 AdmiralRalwood

  • 211
  • The Cthulhu programmer himself!
    • Skype
    • Steam
    • Twitter
Re: Creating efficient models, a coders point of view... (very long post)
As the recent BP rerelease has shown, the memory limitations of a 32-bit executable are perhaps more of a concern these days than the performance impact of multiple 40962 textures; if you have multiple ships with multiple sizable textures, FSO may well just run out of memory before you have a chance to worry about how many FPS the mission will give you.

Hopefully it won't be too long before 64-bit builds start being distributed on a regular basis for Windows, but it's going to be post-3.7.4 no matter what, so those memory concerns will still be, well, concerns for the next stable release, if not the stable release after that.
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 

Offline Axem

  • 211
Re: Creating efficient models, a coders point of view... (very long post)
The advice I give myself when modelling for FreeSpace is, "Don't go nuts. Be smart."

Polycounts should be reasonable to what suits them. Does a fighter need 20k polies? Well I guess its possible. 10k? Probably if its a very prominent player-flown one. 5k? Why not. Modellers should ask themselves "do I need this level of detail? Will I notice it in game?" Do you need 32 sided cylinder on this small fighter, or would a 6 or 12 sided one do? I wouldn't put down any sort of hard-limit to when to stop adding polygons, but if my scout fighter has more polygons than a impressive cruiser, I might rethink some of my geometry. Also consider that collision detection is one of the more prominent bottlenecks the engine has. 20 fighters at 50k polys each close to each other is probably going to cause some slowdowns (as well as shadow map generation).

The biggest thought that keeps my polycount and greeble madness down? "I have to UVMap this, don't I?" If its easy to reduce detail while not cutting down on fidelity, I'd say go for it. If its really hard, eh, I wouldn't worry about it. Let it be a monument to "don't be doing that in the future." ;)

I'm adding these small powerups to JAD and I grabbed this one model from turbosquid's free section. It had 2000 polys, a little high for my taste for a small powerup that the player will barely see. Luckily cutting out the excess polygons was super easy, got it down to 1000. I would have liked around 500, but it needed those polys to keep this bumpy shape that was required.

And on the other side of things, I was trying to import a ship from another game where the poly count was too low! The ship was about 1km long and had around 6k polys total. It looks fine that in game (that game's camera was always far away and the lightning effects were super basic), but once in FreeSpace you could really see the edges up close and it was a really curvy ship, so it was really odd to see bad shine highlights shaped like squares appear. So I had to untriangulate it and carefully set everything up so a smooth operation wouldn't completely wreck the UV mapping. Model poly count jumped up to around 26k polys and the lighting looks a lot better on it now. (Kept the 6km model for LOD1 anyway!)

And with respect to the other more specific points:
Non-manifold geometry isn't an issue, the game will triangulate everything anyway. All the converters I use export triangulated anyway, though I keep my stuff in mostly quad form for easy of editing.
Intersecting geometry should be fine, might need to do the old reset xform trick to solve mysterious collision errors. Uncapped tubes and the like should be fine as well, but you take away UV space from stuff you could jam in there (though personally I'd rather waste the UV space than go through the pain of attaching it properly). You might run into some baking issues with intersecting geometry, but it should be fixable in Photoshop.

These are just my general attitudes to modelling anyway.

 

Offline Spoon

  • 212
  • ヾ(´︶`♡)ノ
Re: Creating efficient models, a coders point of view... (very long post)
^ Solid. ^
Urutorahappī!!

[02:42] <@Axem> spoon somethings wrong
[02:42] <@Axem> critically wrong
[02:42] <@Axem> im happy with these missions now
[02:44] <@Axem> well
[02:44] <@Axem> with 2 of them

 

Offline DahBlount

  • 29
  • Alpine ☆ Cancer Tribulation
    • Minecraft
    • Skype
    • Steam
Re: Creating efficient models, a coders point of view... (very long post)
My current workflow always results in fairly high poly models but I always bake detail into normal maps, so if I were to work on a fighter/bomber, I'd end up with about 20-45k tris, but after baking all possible details into the normal map, I'd have a model with between 5k and 10k tris and good looking normal map. From there I can easily make my textures because I can use the normal map as a guide for drawing detail into the diffuse map. The way I specifically do it is by creating my base model, UV mapping it, model the details, bake them, then remove the details.

Quads are perfectly fine to work with, however you should always triangulate the model before importing into the engine. In many cases, you will also need to triangulate by hand because faces may not triangulate in the way you hope they would, if you have any faces that aren't nearly or perfectly flat, you generally will need to triangulate them by hand.
<Axem> yet still more insightful than #hard-light

<Axem> jad2.23 will just be cat videos

<DahBlount> So
<DahBlount> JAD2.2 is like that
<Axem> maybe
<Axem> it can be whatever you like!
<DahBlount> A Chocolate Sundae?
<Axem> sure

My models: GTF Gilgamesh - GTD Nuadha [Redesigning] - Ningirama [WIP] - GTG Zephyrus

 

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 view... (very long post)
Quality posts. Thanks guys!
"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 zookeeper

  • *knock knock* Who's there? Poe. Poe who?
  • 210
Re: Creating efficient models, a coders point of view... (very long post)
I'd also like to note that when LODding a model, you might want to keep this feature in mind. What I always do when LODding a model is that I make LOD1 compatible with LOD0 collision-wise; I just decrease the number of sides and segments round shapes use, remove tiny greebling, remove small recessions like windows and thruster interiors, and so on.

On fighters you can usually drastically decrease the polycount without perceptible difference. On bigger ships you might be able to decrease the polycount less, but they are usually subject to tons more mesh-level collision checks so it might still help slightly with collision performance. I haven't really ran very detailed benchmarks.


I've learned that it's perfectly okay to have a unique texture for each subobject in the model. What should specifically be avoided is using multiple textures for one subobject. That means it's okay to use a shared texture for turrets, or a debris texture for debris chunks/destroyed submodels, or to put all your subobjects (turrets, radar dishes, rotating submodels, detail-boxed greebles) on a separate texture from the main hull.

Excluding Swifty's new batched model rendering system, the game renders each subobject and texture separately. So if you have a submodel which uses two textures, it should pretty much behave the same way as if it had been split into two submodels, each one using one texture. So, it's good to use as few textures as possible, but if multiple textures are particularly convenient in some case then that's not something to particularly obsess over, as long as the numbers are within reason.


Quads are perfectly fine to work with, however you should always triangulate the model before importing into the engine. In many cases, you will also need to triangulate by hand because faces may not triangulate in the way you hope they would, if you have any faces that aren't nearly or perfectly flat, you generally will need to triangulate them by hand.

Maybe with some exporters? At least when using the 3ds Max OpenCollada exporter, things are triangulated correctly as they are so you don't need to triangulate anything manually.