LEMMA Unadorned Corvette

[pyramid]

The excellent Lemma model by Nózmájner has been recovered and the blender file is in the masters repository.
There are no textures provided so the model needs now texturing.
A pic of the concept for reference:

[Fendorin]

hello Pyramid

i think this ship should be clean before texturing

the turret should be cancel and the front deck ? for corvette is too much
and is over armed? don't you think 4or5 turret for corvette should be enough


even modellers want put all in one ship(all turret all gun a deck massive motor huge space for commercial goods)

if some body can be clean the model before ( now is near 30 000 vertices more than all rlaan station i made) my french computer fall in strike over 15000 vertices

but this one just if you want i texture this ship

maybe Deus siddis could be the remodellers???

[premman1994]

why overarmed...it's cool like that if it's overarmed it's could be slow and have no cargo space...pourquoi surarmer?elle pourait etre surarmer mais vraiment lente et pas de place pour les cargo...et peutetre pas beaucoup d'armure...

[rivalin]

Yup, gotta say that's one quality model, unbelievable that a model that good would probably have just been forgotten about if Pyramid wasn't so thorough with his model roundup.

[pyramid]

The ship design was approved as it is, so it's not my call to comment on the turrets.

As for the model cleaning, I hope a knowledgeable modeler will volunteer.

[rivalin]

If by cleaning you're referring to mesh quality and not aesthetics, then I looked it over and as far as I can tell it's modelled to a higher standard than many of the ships already in the game; nice strips on the ends of cylinders, no obvious smoothing problems etc etc. All the turrets, engines, greebles etc have been modelled as separate objects as well so it should be easy to LOD too.

[Fendorin]

OK is not my problem

i was thinking i wanted help but i can't work over 15000 vertice?edges?poly?
my computer will be so slowly

i m apologies for be impress to reshape it.

[Nózmájner]

To be hones't as far as I remember it has a far less poly count but I can be wrong. If so, sorry about that. I'ts a bit WIP model, so it needs some work to be in an inclusion state.

Fot the armament: I've designed her on Jacks' descriptions and sketch, and I don't think she's overarmed. A pair of cannons, and some point defence, and also a series of torpedo tubes, so she can fullify it's combat support role.

I'm open for suggestions by the way.

[chuck_starchaser]

I think the ship looks gorgeous the way it is. Haven't looked at the mesh, but by the clean looks of it in the pic I bet there's not a single vertex too many; and I think it's time we start putting more polies into VS meshes, for a change, anyways. The urge to spare polygons has far outlived its usefulness. Most videocards' frame rates are pixel pipeline bound, rather than geometry bound. Sure it's more work to unwrap and texture a ship with more polygons, but it is a worthwhile pursuit.
Nózmájner, are you going to finish it? I've been tempted to adopt this baby; but there's too much on my plate right now.

[Nózmájner]

Well, I'd like to finish her, and if I'm lucky, I will have the time during the autumn semester.

Anyway, I've checked the model, and she has a lot of polies for sure, but that can be helped.

[Deus Siddis]

To be hones't as far as I remember it has a far less poly count but I can be wrong. If so, sorry about that. I'ts a bit WIP model, so it needs some work to be in an inclusion state.
Fot the armament: I've designed her on Jacks' descriptions and sketch, and I don't think she's overarmed. A pair of cannons, and some point defence, and also a series of torpedo tubes, so she can fullify it's combat support role.
I'm open for suggestions by the way.

Have you done any UV work on this or your other models?

[Nózmájner]

YUP, I've worked on the UV-s, but most likely they are not very optimised.
Anyway I'm mostly triing to avoid overlaping

[Nózmájner]

Anyhow, don't touch her too much right now. I want to optimize the model, before any texturing work.
Anyway, can somebody properly brief me on poly counts of lods and classes. I've looked trough the forums a while ago, but I found more then one version.
And also, is it have to be triangle count, or quad count of the same is good too?

[chuck_starchaser]

Vertex count is a simpler and more relevant metric. There's no hard and fast rule. 1 million is too many, for sure. A quarter million is a bit heavy, but okay for a space station or large carrier. The smaller the ship, the less complex the mesh should be, and the smaller the textures. That's about it.
Well, for a small fighter, a lower bound would be 3000 vertices; and an upper bound say 30,000.
What slows down videocards is the sizes of the textures, really; so I advocate 512 for fighters, 1024 for corvettes, 2048 for large ships, stations and planets.
Having said all that, if you put a lot of vertices on a fighter, like 20,000+, or even 10,000+, you start facing another problem: Texturing. Why? Because if you're trying to limit your texture to 512, you find that many of your geometry details scale to sub-pixel sizes.

As for LOD's, the important thing is to have at least one very simple LOD, a few hundred to a thousand vertices. Having a middle LOD is icing on the cake.

[Fendorin]

i never knew we can push the vertice like that 30.000??
i thought it was a joke!

[chuck_starchaser]

i never knew we can push the vertice like that 30.000??
i thought it was a joke!

No joke at all.
PU's Cutter corvette I think it's 70,000 or 80,000 polygons, and no problem at all That's a 100 meter long ship, btw.
The crappiest videocards today can process 100 million triangles per second. That works out to 1 million triangles on-screen at 100 FPS.
What chokes the poor videocards is big textures, overdraw, lack of LOD's, and poor texture management; --all of which revolve around the problem of memory size and bandwidth. And yet most people keep talking about "poly count" as what counts for performance.
It's probably the *last* thing one needs to worry about, nowadays.

[HoodedWraith]

i never knew we can push the vertice like that 30.000??
i thought it was a joke!

No joke at all.
PU's Cutter corvette I think it's 70,000 or 80,000 polygons, and no problem at all That's a 100 meter long ship, btw.
The crappiest videocards today can process 100 million triangles per second. That works out to 1 million triangles on-screen at 100 FPS.
What chokes the poor videocards is big textures, overdraw, lack of LOD's, and poor texture management; --all of which revolve around the problem of memory size and bandwidth. And yet most people keep talking about "poly count" as what counts for performance.
It's probably the *last* thing one needs to worry about, nowadays.

When I was working on stuff before and writing the basis for a fighting game (that subsequently got nixed due to college irresponsibilities, and we changed our name from Fractured Minds to Dreadnaught Games, went from PC to pencil and paper gaming) one of our modelers was constantly going on about how I'd need to rethink most of my character concepts to lower poly counts. I've been laboring under the assumption that higher poly counts were horrendously evil.

[chuck_starchaser]

Poly counts WERE horrendously evil when "3D accelerator" videocards used to only accelerated the texturing process. The CPU had to do all the geometry transformations.

But NVidia introduced T&L back I think it was in 2000. By like 2005 or 2006 already the speed of GPU accelerated T&L had gone far beyond ever possibly being the bottleneck.
So the bottleneck for graphics, now, is the same as for CPU's: Memory.
Now, the mesh of a typical VS ship takes at most 100K of space in memory, whereas its textures typically take dozens of megs. Doesn't take a genius to figure out where the bottleneck is.

The problem is that worrying about polygon counts became a habit and a tradition and a part of the culture. It's like the sound technicians culture, a bit; where no sound technician knows the first thing about the physics of sound, and say absurdities and atrocities like "this brand of speakers doesn't sound as loud, but it 'projects the sound better' ... ...; but they all assert their authority by round-robin attestations of each other's authority. Same thing here.

[Fendorin]

it's means all the ship i made, its good for will go to garbage??

and on my computer when they have maybe 5 or 6 OX or 1 with station in my screen even near a jump point the speed of the game is slow down a lot
and my computer is brave and not so bad

[loki1950]

There is another issue with the Jump animation Fendorin that is most likely the cause of your slow down it has been fixed in the svn version.

Enjoy the Choice

[Fendorin]

i had the same problem when i open the "view all ship mission" when i turn my ship into the "field of ship" direction iy was very slow like one picture each second

and this ship didn't moove

[chuck_starchaser]

There's a very old bug when you view things very close; I think it only happens with NVidia cards, and it's a problem with the vertex shader. Klauss identified it, and he was thinking of having separate shaders for NVidia and ATI, because ATI prefers to have macros for loops, whereas NVidia prefers to have actual loops. But that's a bug; not a real issue of performance; and it happens independently of the amount of geometry you have in the scene.

There's nothing wrong with your ships, though, Fendorin; they are beautiful; but I guess they will eventually have to become the second LOD's of themselves...
Hmm... Make that the third

And 30,000 would be max for a fighter; for a station I'd say 300,000. I mean, I tried to tell you many times, Fendorin; this is not the 90's any more; and the engine is not Doom's or Descent's. Your models have such low poly counts it's as if you were making ships for an old DOS game back in 1995. We're in 2008, and the technology has advanced a lot.
Do this for an experiment:
Take any of your ships and apply subsurf at level 2, 3 or 4, until you get 10 or 20 thousand polygons, export obj, and throw it in-game, and see if you see ANY difference in frame-rate.

EDIT:
But thinking as a modder, though this is not my mod (PU is), I'd say your ships are very nice as they are, and would place higher priority to getting the rest of the ships done, than on increasing detail for the ones already done. But it would be great if you were to finally believe me and start putting more details on future models. Nothing should be less than 3000 polygons or vertices, really; not even the smallest fighter. Well, maybe drones, missiles, torpedoes and such things yes. No corvette should have less than 20,000 polygons. Space stations should be like between 100,000 and 500,000 vertices. Otherwise, as a player, how can you even tell that they are big? You need lots of little details to convey the huge size of them.
One thing to keep in mind, though, for performance, is that there's a limit of vertex indexes per-mesh beyond which performance slows down dramatically. That's vertex *indexes*; not vertices; and the number of vertex indexes for a mesh is not easy to judge; but as a rule of thumb, keep it under 10,000 vertices per mesh.
So, a 100,000 vertex space station should be exported as 10 separate .obj's, 10,000 vertices each. They can all share a common texture, though; and it's best for them to do so; but you can also have some meshes have a separate texture when necessary. For instance, lights and transparencies, like glass, you probably want to keep them in their own, separate mesh, and maybe using a separate texture.

[Nózmájner]

That's some useful information. I think this and some other stuff should be usefull to be summarized in an FAQ or something. At least I would have some questions, like how about overlaping UV-s in a single model, or about intersection of different meshes can be used (I don't like it by he way), or the poly count bounds for different classes and LOD-s, and texture sizes.

So in conclusion, there's no need to cut down the poly cound, and it can be used as a top LOD? If so, the model does need some tuoch-up, and a LOD of course, and I think, I start working on it today.
Should I keep the different sections on different objects, or join them up?

[chuck_starchaser]

That's some useful information. I think this and some other stuff should be useful to be summarized in an FAQ or something.

Okay; I'll try and make a wiki page out of it, or add it to an existing one; good idea.

At least I would have some questions, like how about overlapping UV-s in a single model,

Short answer: Don't overlap or mirror anything (almost).
Long answer:
Eventually we will have engine support for dual UV-mappings; and we will (optionally) be doing two unwraps per model:

• A non-overlapping or mirroring unwrap, used for ambient occlusion/PRT bakings, normal-map, light-map/radiosity, damage and decals (faction-specific writings and logos).
• A mirroring and maximally overlapping unwrap, for diffuse, specular and glow textures.

But until we have dual UV's, the worst thing we can do is something in the middle; because then none of the work we do will be re-usable; and going maximally overlapped would leave us unable to have ambient occlusion now. So, by elimination, that leaves us with only one choice: doing a purely non-overlapped unwrap, for now.
However, I said "almost" because there are a few exceptions: Objects that are black in diffuse AND specular AND glow, --pitch black--, are lighting-agnostic, so their islands can all be overlapped together into a tight bunch, and then shrunk to a single texel and put in a corner out of the way.
Similarly, all islands for red lights that have the same intensity of red glow and are black in diffuse and specular, can be bunched and shrunk together. Same with all green lights. Same with all blue lights, yellow lights, etc.

or about intersection of different meshes can be used (I don't like it by he way), or the poly count bounds for different classes and LOD-s, and texture sizes.

Intersecting meshes is not exactly a NO-NO, and sometimes it makes a lot of sense if a boolean union would produce a gazillion polygons, such as when a pipe enters a plane. However, it is much better to have the pipe end exactly at the surface, or even be off the surface by a micron, than to actually penetrate; because when it penetrates, you get dark, semi-buried texels there when you bake an ambient occlusion or radiosity.
Also, the biggest performance concern is over-draw: Overdraw occurs when you have surfaces covering surfaces on the display. Within the area of coverage in screen-space, the GPU will be drawing each pixel twice, and deciding coverage based on z-buffer comparisons, pixel by pixel. As a rule of thumb, you shouldn't have large, hidden surfaces anywhere.
http://dungeonhack.uesp.net/forums/view ... =1775#1775
If you go inside the model, you should see a Great Emptiness, basically; --i.e.: The outside surface viewed from inside, and nothing else. So, if two inter-penetrating shapes are too hard to weld together, but they interpenetrate over an area, do, at least, make a hole in one that roughly removes 90% of the covered area, and trim the other short.
Finally, consider welding the parts together, even if it's not easy; it usually looks much better. Wings that penetrate a fuselage make a plane loook like a toy. Smooth-welded wings look a lot more real and professional. See Smoothly Welding Complex shapes.

So in conclusion, there's no need to cut down the poly count, and it can be used as a top LOD? If so, the model does need some touch-up, and a LOD of course, and I think, I start working on it today.

Cool!

Should I keep the different sections on different objects, or join them up?

However you prefer to work. I usually keep separate objects during the construction phase, and join them once I consider them finished. At the time of exporting, you'll want to have meshes for the top LOD that don't exceed 10,000 vertexes each. In Blender, my latest idea is to keep metals and dielectrics in separate meshes. That's because in Blender there's a limit of 14 material indexes per object, and that's too few, so 14 metals and 14 non-metals suits me better. Lights and transparencies (cockpit glass) are best put in a separate mesh, because transparencies use a different blending mode; and lights will use the same shader as transparencies, if you eventually target the CineMut shader family. (There will be CineMut Opaque; and CineMut FireGlass for glass (and plexi-glass, whatever) and emissive surfaces. Note: You'll still be able to use glow in CineMut Opaque, but CineMut FireGlass will have additional features, like defining directionality for lights, so that engine glows look brighter when you're aligned behind a ship.)
And then, for each top LOD object, you have one or two lesser LOD objects. Then you export one .obj per mesh object. That's what I do; though you can have a greater number of objects and select several at a time at export time, if you prefer.
Finally, you may want a separate object for the shield; and optionally another object with tiny cubes where the engine plumes and weapons and pilot are positioned, so you can read their positions easily when calculating the numbers for units.csv.
AND, you may (WILL) want to have "LOD ZERO" for each of your meshes: High poly versions you use for bakings, including ambient occlusion, radiosity, and last but not least, a corrective normal-map.

EDIT:
One more thing, make sure you rotate all your islands so that the direction towards the front of the ship always points straight UP in the texture. This is because if you want to use linear blurs to represent dirt streaks and scratches, you'd rather do so using a global mask, that have to do angled linear blurs for each island. Also, if you later decide to use LaGrande to make dirt-streaks, LaGrande fades the streaks downwards, always.
By the same token, front- and back-facing surfaces, which don't have a front to back way of aligning them, and on which you don't want streaks, you want to put them all together where you can mask the streaking easily; preferably along the top of the texture.

EDIT2:
Forgot to mention, the engine does not require it, but it is a mighty good idea to provide separate, reduced versions of the textures for each LOD. Otherwise, if a ship is beyond visual range, only the smallest LOD of the mesh is used, AND the lowest mip-map of the textures; but the full textures have to reside in the video-card taking up a lot of space, even if only the last mip-maps are being used.

[Nózmájner]

Thanks for all the help.

About that one in the end. That stuff about rotating all the islands front to the up. That's for some automaticly generated scars and dirt?