Author Topic: NTF Iceni [WIP]  (Read 17850 times)

0 Members and 1 Guest are viewing this topic.

Offline Rga_Noris

  • 29
  • What?
MS Paint...

Seriously though, hop into the IRC channel #scp-fsu. Many FSU heavy weights hang in there and are helpful.
I think I'll call REAL Mahjong 'Chinese Dominoes', just to make people think I'm an ignorant asshat.

 

Offline Alan Bolte

  • 28
  • Deneb III
    • @Compellor
Some thoughts on adding detail:
The front of the two lower nacelles evokes the front of Hades' Deimos' lower nacelle. A similar style of greebling might work there.

The area immediately above the front of the nacelles should have more armor panels, to evoke the retail texture.

The upper half of the front of the main hull should have the densest collection of greebles. Pipes, struts, hatches, vents - go nuts!

On the back, between the engines, the retail texture has some sort of enourmous brackets, plus vertically oriented, horizonally striped columns or pipes.

For the front face of the forward hull, the panel lines from the golden retail texture could be copied more or less as-is.

I like the relatively clean look of the port and starboard faces of the main hull. It could use some gentle panel lines, but nothing fancy.
Anything worth doing is worth analyzing to death -Iranon

 

Offline Tomo

  • 28
Guys, there's no 'right way' with this... Stop arguing like there is. There are pros and cons to either method and they both work just as well. Yes, you could save a little UV space. No, you won't kill the engine with little render mesh N calls or whatever Tomo is thinking. Alternatively, you could copy your little details as many times as necessary and save time modelling and UV mapping while also having your polygons match exactly and have an easier time texturing later.

I've done both. Many times. Both work juuuuuuust fine.
All that's true. (Though it is possible to break the collision detection, that's fairly rare and should be easily fixed.)

Modern model-related slowdowns mostly come from excessive OpenGL state changes (eg render calls) and from running out of GPU memory.
The former has a relatively small effect so only matters for 'many ships', the latter has a very large effect.

The actual number of polygons and vertices is doesn't really matter these days. (As long as it's below the maximum allowed.)
Vertices don't eat much GPU memory, textures do.

What I meant was that using 'many subobjects to save polygons' as a rendering optimisation technique actually has the opposite effect.

If you're using subobjects to make your task of building the model, texturing etc easier then great, do it!
The time you and others spend to create the model and get its gorgeousness into the game is far more valuable than the time the GPUs will spend rendering it.

All details aside, in a capship 'small optimisations' like this don't really matter anyway as there's never going to be very many capships in a mission!
These kinds of tweaks only make a difference if there's lots of them.

 

Offline Rga_Noris

  • 29
  • What?
Guys, there's no 'right way' with this... Stop arguing like there is. There are pros and cons to either method and they both work just as well. Yes, you could save a little UV space. No, you won't kill the engine with little render mesh N calls or whatever Tomo is thinking. Alternatively, you could copy your little details as many times as necessary and save time modelling and UV mapping while also having your polygons match exactly and have an easier time texturing later.

I've done both. Many times. Both work juuuuuuust fine.
All that's true. (Though it is possible to break the collision detection, that's fairly rare and should be easily fixed.)

Modern model-related slowdowns mostly come from excessive OpenGL state changes (eg render calls) and from running out of GPU memory.
The former has a relatively small effect so only matters for 'many ships', the latter has a very large effect.

The actual number of polygons and vertices is doesn't really matter these days. (As long as it's below the maximum allowed.)
Vertices don't eat much GPU memory, textures do.

What I meant was that using 'many subobjects to save polygons' as a rendering optimisation technique actually has the opposite effect.

If you're using subobjects to make your task of building the model, texturing etc easier then great, do it!
The time you and others spend to create the model and get its gorgeousness into the game is far more valuable than the time the GPUs will spend rendering it.

All details aside, in a capship 'small optimisations' like this don't really matter anyway as there's never going to be very many capships in a mission!
These kinds of tweaks only make a difference if there's lots of them.

It's unclear what point your trying to make. You're listing valid points, and then downplaying them.

1) "The actual number of polygons and vertices is doesn't really matter these days. (As long as it's below the maximum allowed.)"

This number is VERY easily hit with modern ships these days. So any technique that can lower the vertex count will cause fewer head aches later.

2) "What I meant was that using 'many subobjects to save polygons' as a rendering optimisation technique actually has the opposite effect."

How? If you are referring to UV map wastage, there are plenty of techniques that minimize or eliminate wastage (nothing stops you from drawing in the occluded portions where non-manifold polies intersect...) However you do seem to have a better grasp on this than I do, so I concede that I may be missing your point here.

3) "...there's never going to be very many capships in a mission!"

People love to whore out cap ships. The other thing is fighter poly counts are climbing as well. We see missions with more and more ships because FSO makes it possible, so trying to use that as a point is pretty short sighted.

So in conclusion, there still is little to no reason to make your mesh entirely manifold.

EDIT: Apologies for the rude flavor above. I would just change it, but in the off chance you are reading this before I can, i'll just tack it on. My main point is that if we agree that:

1) Multiple sub-objects = slower game

AND

2) Hitting the subobject vert limit more often means you must have more subobjects

Then the only conclusion is that fewer verts and polies = better performance, just not for the reason that most people think.
« Last Edit: January 11, 2014, 07:19:34 pm by Rga_Noris »
I think I'll call REAL Mahjong 'Chinese Dominoes', just to make people think I'm an ignorant asshat.

 

Offline Tomo

  • 28
I'll try to write an analogy that might help.

Think of rendering as physically sending stuff somewhere.

The models are packed into crates (subobjects).
When run, the game puts each of these crates onto its own van.

Each frame, the game tells the GPU driver which vans need to go to the screen, the order to take them and what to do with each one.
If the driver runs out of vans (GPU memory), then it has to store the stuff in your warehouse (main RAM) instead, and swap it between vans.

"Take Van #1" - GPU drives Van #1 to the screen, Stuff Happens and it comes back.
"Take Van #5" - GPU drives Van #5 to the screen, Stuff Happens...

It's obviously fastest if everything fits into one van.
However, if your stuff won't fit in one van, more trips are necessary to send the stuff.

If the game knows that a particular van isn't necessary it can skip it - this is the purpose of detail boxing.

To stretch the analogy a little further:
If you run out of space in your warehouse then your logistics manager (operating system) has to store it in another, much bigger warehouse out of town (hard disk).
That's incredibly slow, we really, really don't want to do that.

(This is a lie-to-children* of course. It's more complicated than this.)

In conclusion, fewer vans makes your ship go faster.
How you get fewer vans depends on the model - and it's always possible to go too far in one direction.

My last point is that your time is more valuable than the computers time, so as mjn said, you shouldn't worry about any of this too much unless it becomes a problem.

* Ref: Dr Cohen and Prof Stewart

 

Offline Rga_Noris

  • 29
  • What?
Great analogy, even if it was mostly to confirm what I thought.

I am mostly addressing your original meaning: "What I meant was that using 'many subobjects to save polygons' as a rendering optimisation technique actually has the opposite effect."

It misses the mark. Non-manifold is not equal to multiple subobjects, which I think is where the confusion set in for many. And reducing polygons does matter, and your van analogy states why.

Each van holds 65535 vertices. The fewer vertices I have (and consequently, though not proportionately, fewer polies) the fewer overall vans I will need. Hence, better performance. Case closed.

Finally: "My last point is that your time is more valuable than the computers time, so as mjn said, you shouldn't worry about any of this too much unless it becomes a problem." Not the way I see it. If my model is too ineffecient, then I wasted my time, as fewer people will be able to play it.
I think I'll call REAL Mahjong 'Chinese Dominoes', just to make people think I'm an ignorant asshat.

 
For me, the Iceni is now nearly finished (except the Meshoptimization, this will be done as the last step.

Just a question to all of you: Would you like to see the Iceni more like Hades´ Meshs? I mean with extrudes Armorplates or would you prefer a more "clean" look, for example at the mainbody, where the engines are.
I will do this by your wishes because this model is, of course, not just for me. It´s for all of you :-)

An updated version of the mesh will be uploaded at p3d today, but later because my officeday still started.

Thanks in advance for your opinions und your reply.

Cheers, Lc4Hunter :)

 

Offline Nyctaeus

  • The Slavic Engineer
  • 212
  • My "FS Ships" folder is 582gb.
    • Minecraft
    • Exile
Just a question to all of you: Would you like to see the Iceni more like Hades´ Meshs? I mean with extrudes Armorplates or would you prefer a more "clean" look, for example at the mainbody, where the engines are.
I found it as a bad idea, and the reason is very simple. Single extruded armor plates are waste of numbers of polys. Things like this are usually done via diffuse and good normalmapping.
Exile | Shadow Genesis | Inferno | Series Resurrecta  | DA Profile | P3D Profile

Proud owner of NyctiShipyards. Remember - Nyx will fix it!

All of my assets including models, textures, skyboxes, effects may be used under standard CC BY-NC 4.0 license.

 

Offline Enioch

  • 210
  • Alternative History Word Writer
Just a question to all of you: Would you like to see the Iceni more like Hades´ Meshs? I mean with extrudes Armorplates or would you prefer a more "clean" look, for example at the mainbody, where the engines are.
I found it as a bad idea, and the reason is very simple. Single extruded armor plates are waste of numbers of polys. Things like this are usually done via diffuse and good normalmapping.

I'm not that sure about that. What Betrayal says has merit - a good normal map is quite capable of bringing a flat polygon surface to life. However, consider what a 'good normal map' would entail for a ship the size of the Iceni. You'll need multiple 2048^2 maps, to cover the entire ship with uniform pixel density and they will be blurry and smudged up close. Plus, the multiple maps will hog a lot of resources. Since FSO really crunches polygons for breakfast and spits out beamz, I believe that you can get away with Hades-like armoring on LOD 0, heavily reduced in LOD 1.
'Violence is the last refuge of the incompetent'  -Salvor Hardin, "Foundation"

So don't take a hammer to your computer. ;-)

 

Offline General Battuta

  • Poe's Law In Action
  • 214
  • i wonder when my postcount will exceed my iq
Like Enioch said, polygons are really cheap, it's pretty hard to waste them.

 

Offline Hades

  • FINISHING MODELS IS OVERRATED
  • 212
  • i wonder when my polycounts will exceed my iq
    • Skype
    • Steam
I also realized that in my package with the two turrets, I sent the wrong Deimos turret.

http://www.mediafire.com/view/54ljrqbr3keo9lc/bigturret1d.obj

Here's the old, angular one, in case you want to use it. :)
[22:29] <sigtau> Hello, #hard-light?  I'm trying to tell a girl she looks really good for someone who doesn't exercise.  How do I word that non-offensively?
[22:29] <RangerKarl|AtWork> "you look like a big tasty muffin"
----
<batwota> wouldn’t that mean that it’s prepared to kiss your ass if you flank it :p
<batwota> wow
<batwota> KILL

 
Latest version:


Some details are currently missing, like some greebleparts at the rear of the mainbody (engine-section) and the front (the eyebrows for example).

The polycount is absolutly ok, i can add some more without any problems ;-)

i know, the progress is not much, but i had a lot to do at work and with my EA Warlock model... if you´re intrested, its in the galery.

 

Offline Rodo

  • Custom tittle
  • 212
  • stargazer
    • Minecraft
    • Steam
Great progress if you ask me.
The Warlock and that asteroid base look awesome as well :yes:
el hombre vicio...

 

Offline Hellzed

  • 28
@Rodo : Asteroid base ? Are we talking about the Boadicea ?

 

Offline Commander Zane

  • 212
  • Spoot Knight of Anvils
Narn asteroid base.

 
I really like it, especially the ribs on the belly and the bottom engines, which look like an enlarged version of those of the (still unfinished?) upgraded Apollo :)