Hard Light Productions Forums
Hosted Projects - FS2 Required => Inferno => Topic started by: Rampage on September 15, 2012, 05:55:14 pm
-
Hello HLP Community, this thread will serve as the development of the GTSD Bastion, a GTVA Terran superdestroyer that features in the current development vein of Inferno.
http://p3d.in/v1nmH/wire
As of 09/15/12 it is 45% done. I also apologize for smartphone holders and those who cannot p3d, but I cannot upload images at this moment. Also this mesh does not have smoothing yet, so it's best viewed in wireframe. Please critique it and give us your ideas on how to make this model.
R
-
I find "wire on shadeless" a better option than a wireframe.
-
Is this a replacement for the Icanus?
-
Is this a replacement for the Icanus?
No. This will be the replacement for the Warlock's current replacement.
R
-
looks like a Vasudanised Orion. Be interesting to see where you take this one
-
:eek: sect. C!
-
If you'd like to see what the original model looked like, its in the Wiki HERE (http://www.hard-light.net/wiki/index.php/GTSD_Bastion).
-
It was like, totally my favoritest design back in the day, because in the Freespace as I know it, Vasudan-Terran integration wasn't pulled off that well and this design did that pretty well. Never thought I'd live long enough to see it in a campaign ;)
-
No. This will be the replacement for the Warlock's current replacement.
Not really since it isn't a carrier. It's the Terrans counter to the Nemesis would be more fitting.
The backside were the main engine is is showing completely flat there. Is that part not fixed up yet or has the model format chopped it off for some reason?
-
Not really since it isn't a carrier. It's the Terrans counter to the Nemesis would be more fitting.
So it's the replacement for the Odin?
-
P3D works fine for me ;)
Xperia S ICS.
Model looks very very similar to the original...
-
The old model in technical terms was a disjointed non-manifold mesh that had too many geometry errors to count - - enough to crash my older version of Blender; so far the only thing I did was cleaning it up of all those errors and made the mesh manifold and added edges to guide me in detailing it. The engines will probably be worked on last, and the side fighterbay will be booleaned to the main mesh after the two parts of the model are UVmapped for future generations (the mesh will still be tilemapped for the upcoming release).
R
-
Rampage, just gotta say two quick things about how FSO works
1) Non-manifold is absolutely fine - every model I make is either non, or open manifold. This doesn't matter, you know why? Because in FSO, when you have smooth groups, it separates the edges anyway and becomes open manifold, thus its pointless to ensure that the mesh is closed-manifold.
2) Don't boolean things together if you do not absolutely need to, it just adds wasted polies, and introduces more opportunities for lighting and smoothing errors. I know this might be a personal preference thing, but just do know that the model can be composed of multiple fused and non-booleaned objects. (In fact, when you get to higher polycounts ie. UED Solaris, this is in fact necessary, to split the model into subobjects to avoid the per-subobject polygon limit)
Just trying to make sure you're not working with any incorrect assumptions with regards to what is required to make a properly-functioning mesh for FSO.
-
Thank you for your suggestions. I am fully aware that FSO can support non-manifold meshes, and non-manifold is fine, but geometry errors are not. And being a common cause of non-manifoldness in meshes, IMO all geometry errors must be eliminated during development so the mesh is easier to work with. FSO can tolerate many of these errors but in my OCDness I cannot, so it's purely my personal preference. As for booleans, I know some people avoid them like the plague, and I for one never overuse them. And with your suggestion, I just might keep the hangar separate from the main mesh. :) However, booleans are powerful if (1) you know how to use them and (2) you're willing to clean up your mesh afterward.
Anyway let's get back on topic. If you further wish to share your opinions on modeling, please do so on the internal or send me a PM.
R
-
Is it replacement for Odin or Solaris or one-a-kind Flagship (I thought Solaris play that role)?
BTW It looks like mix of old Orion R1 Warlock + advance post-Capella tech.
-
*snip
Booleans are by no means bad things, but like any tool, they have to be properly used. Any mess you make must be cleaned up, and any bad geometry has to be dealt with (kind of a redundant statement, but whatever). Subdivisions are also a tool, but using them properly is even more of a challenge. The model must be cleaned up afterwards, and the polycound has to be cut down to size after a commit. Retaining the target dimensions also becomes a problem, as most programs tend to shrink geometry at the peaks and fill in the gaps. Some software may require you to break pieces apart and then re-join them, or may let you define sharp edges and chines, but are a real PITA to use. Both of these things are great tool, but by no means do they make labor easier when you know what you're up to.