MECHANIST Starship (manuel of style purpose)

[Fendorin]

Hello here by this thread i search to open a "canon and manuel of style work"
first a constat:
1/a lot of contributor ( and now far to this forum) had searching a advise for be close to the manuel of style , (but true it didn't exist.
2/ picture are more explicit than a writting a page
3/except Rlaan and Aera, the Style of ship are difficult to differentiate between the human faction,

then i discover a Python script for Blender (dicombulator) and i was thinking is a good tools for do a Mecanist ship and installation .
Some one will tell mee is "too artificiel difficult to control..."
But is the purpose of Mecchanist : be too mathematic artificiel no?

Then if the "Style" of the ships and the installations below are approuved (by JackS) it will be really easy to produce a Mechanist's ships + the installations :
Maybe the Patrol boat MK 460 :

A splash screen: docking at station or Shipyard:





Proposition for a mechanist's style station (civilian). It look like with a part for other organic species :
Or i could be unadorned



And some quick 3D sketch for Shipyard :


and this installation, the ship upper was docked :


And a weapon turret :






Then Jack's advise are calling

[chuck_starchaser]

Fendorin; this looks terrific, but I guess you've just discovered "discombobulator"...
Two words of caution:

1) Not sure if it's been improved... last time I used discombobulator was a year or two ago, but when I did,
I found some nasty aspects to it: First of all the boxes tend to overlap each other a lot, so I would spend
a lot of time deleting boxes that contributed little, or that were completely hidden inside other boxes. Also,
the boxes have useless bottoms, which also need to be manually deleted. Finally, discombobulator would be
so much more useful if it automatically placed seams; but it doesn't; you have to manually mark seams.
One way to do it moderately cheaply is to have all boxes in a separate object, select all (A), mark seam;
then manually select all top surfaces and clear seam. Unwrapping is still a lot of work.

2) If you cover large surfaces with boxes, you have to know that this will result in a lot of overdraw; which
is the Enemy Number One of display performance. At run-time, the GPU will draw both surfaces on the
screen: the bottom surface AND the box that covers it, and which write wins will be decided on a pixel-by-
-pixel basis, based on z depth comparisons. That's why I always recommend to people not to have large
floating geometry covering large surfaces.

This is not to say one shouldn't use discombobulator; but it'd be a good idea to minimize its use to small
areas. You can, for instance, use texture and normalmap tricks on a surface, then put a rectangular recess
somewhere, for variety, and use discombobulator inside that recess.

And a third word of "artistic" caution:
Discombobulator is the darling of StarWars modeling. If you over-use discombobulator, you're basically
making StarWars ships and stations, to many people's perceptions.

[Fendorin]

1) Not sure if it's been improved... last time I used discombobulator was a year or two ago, but when I did,
I found some nasty aspects to it: First of all the boxes tend to overlap each other a lot, so I would spend
a lot of time deleting boxes that contributed little, or that were completely hidden inside other boxes. Also,
the boxes have useless bottoms, which also need to be manually deleted. Finally, discombobulator would be
so much more useful if it automatically placed seams; but it doesn't; you have to manually mark seams.
One way to do it moderately cheaply is to have all boxes in a separate object, select all (A), mark seam;
then manually select all top surfaces and clear seam. Unwrapping is still a lot of work.

I had this conclusion very quick too. Sure is not a "game oriented tools".

2) If you cover large surfaces with boxes, you have to know that this will result in a lot of overdraw; which
is the Enemy Number One of display performance. At run-time, the GPU will draw both surfaces on the
screen: the bottom surface AND the box that covers it, and which write wins will be decided on a pixel-by-
-pixel basis, based on z depth comparisons. That's why I always recommend to people not to have large
floating geometry covering large surfaces.

I don't understand the Gpu Side or the 'Architecture' of engine game.
but i understand the balanced ratio : poly vs visual quality

I thought if i was a "creative" director i will push the mechanist art part too the direction of "Discombulator looking"
But like always, a magic tools never exist then the Artwork upper need to be copied by hand modeling.
Because we cant use a model made with a lot of plain boxes plus i did a constat : after looking the "construction" of the mesh maybe just 20% of the alls cubes surfaces are visibles.

And for be complete i tryed a auto uv mapping and baked after is ugly
on the upper picture is a seams less Ortho 1024 pot set of picture i made. then the render is correct
but about use in game? could we use this kind of setting or all should be unwrapp?

Is always good to have an advise and a idea/knowledge echange.(but true i take more than i give hihi )

I didn't know for the "double mesh coverage" thanks i saw on net. some tips about greebling but never that thanks!!!!!
i will try to take care about that

Thanks

[chuck_starchaser]

The problem of overdraw (large surfaces covering large surfaces) is very important to understand well.
I explained it with visual examples to the guys of Dungeon Hack, at their forum here:
Optimizing Meshes -- Minimizing Overdraw

EDIT:
I've nothing against mechanical greebles, of course. What I was saying is that ***random BOXES***, as produced
by discombobulator, are the hallmark of StarWars. It's a drastic change in directions for VS art; and it is also
of lesser quality: Pure boxes doesn't look like realistic mechanical stuff. Sparse boxes connected by piping, for
example, would look a lot more realistic.