Dynaverse.net
Taldrenites => Starfleet Command Models => Topic started by: FoaS_XC on October 08, 2010, 12:03:55 am
-
[youtube]yf3nyO8Vz6o[/youtube]
So thats my idea. What do you guys think?
-
Good idea. Are the parts going to be compatible with Blender?
-
Sounds good what about MS3D?
-
I don't know blender that well, but I'm sure we can work something out.
MS3d would be much harder to work with because it is very limited. for one MS3d has no boolean or render to texture capabilities - Something which I think will be necessary to get the full benefit of what I have in mind.
-
I like it.
Standards and standard operating procedures are good. So long as what they say makes sense. And I think you're making sense.
Major coding projects have coding style guides, as do major writing projects. Why not a SFC/Dynaverse.net model style/standards guide? Which I expect will come about as a result of what you have proposed if it takes off.
Define classes properties and methods, make it code ready.
By class in this context I mean low poly, standard, enhanced, artistic, and pestalence's gaming machine grade. ;D Properties such as, isLODed, isHardPointed, Model/PartVersion, ShipClass, GameRace... Those sorts of ideas. Perhaps I jump the gun, but perhaps an xml def... for the parts/models, something to help sort them before they proliferate as I suspect they might. (hang on... would it even be possible to pre-hardpoint? ... I think so, they'd just need renumbering after assembly?)
In general I like the concept. But artists are a wild bunch so we can't be offended if people want to go their own way, and we should do our best to find ways of including as much variety in style as possible so long as minimum standards are met. (?)
I'm thinking associated web app repository already, akin to the battleclinic community docks, but where you can select a bunch of parts and have the server zip them all together and send as one file package for you. Ideally with a thumbnail preview of eaech part for the browser, or better yet a collada version of the part in the package for display on a canvas element in the parts package builder ;) ...just brainstormin...
-
Now, a problem I see with this is that it won't be as easy as just booleaning everything together and merging the psd's into textures. You'd have to have a pretty good idea of how to fix up booleans (because they are messy after all), mapping and working in Photoshop. Not everyone tried something along the lines of me with the Luxor fleet, where you have 24 ships with a total of 8 textures, with one ship using a max total of 6 (4 main (2048x2048 rez) and two (256x64 rez) identical ones for the inner and outer plasma grid pair - the mapping setup I've been using since, with the exception that with SFC's engine, you can safely drop the two grid textures and throw the grid onto the nacelle texture), or 5 ones (ships without a secondary hull). It's not an easy job, you'd have to think through a LOT of things, and here I'm thinking about the guy doing the bashing. You would have to teach each and every one of them how to do it properly.
-
The fixing of booleans is not as hard a problem as I once though. Basically all you need to do is select all the verts that only link 2 edges (I have a maxscript that does this) and remove them.
As far as textures - I think you are right. That will be the biggest hurtle. I'm inclined to think that an auto map on the second channel, then render to texture (like I describe in one of my videos) is not a bad idea. this way it uses just the textures it needs.
Bonk - I love what you are thinking.
Obviously not everyone will want to walk to the same drum, and that's perfectly fine. I think a web-service that lets you pick and choose your parts would be neat, but the person would have to assemble the parts and do all the post work themselves. I do think that if we were to do this we do need a "standard of modelling" though
-
Just farting around with new shapes.
(http://img194.imageshack.us/img194/2856/variationsw.jpg)
These aren't final versions as they still need to be finished up, mapped, etc.
-
ONLY 3800 TRIANGLES?!?!?!?!? I've got to get out of the stone age.
I think this is a good idea. In a way, I sorta do this already with my stuff. On the Boolean, wouldn't it keep the polies down and the design of parts simple if you had each piece as a single-void solid instead of the whole vessel a single-void solid? As far as I can tell, SFC3 is the only one of the four that has fits with that.
For sure, a directory of pre-textured parts that are all to scale would be a huge contribution!
-
Having a watertight vessel does have its advantages. For one, when you zoom out far enough, you don't get overlapping triangle errors. For another the break models are much easier to make. The increase in polycount isn't really that bad. In some cases its actually decreased my polycount (because you don't have the occluded faces anymore).
Edit: also, a watertight mesh makes that GI-baking I do easier, but I know that that's not everyone's cup of tea.
-
GI-baking? Do teach!
-
A link to the video tutorial series I did on it.
http://www.robinomicon.com/c/articles.php?article_id=5
-
Just farting around with new shapes.
([url]http://img194.imageshack.us/img194/2856/variationsw.jpg[/url])
These aren't final versions as they still need to be finished up, mapped, etc.
Mind if I get a copy? I'd love to see how you've made yours, and also take a closer look at their designs. For my next ship, I'm thinking of doing a Constellation refit.
-
Sure - but let me get a bit further along the process of getting the kit out.
-
Nacelle Texture test.
(http://img219.imageshack.us/img219/7993/nacelle1.jpg)
-
Nice, teal FTW! :D
-
Yeah, thought you'd like that.
The way that I'm setting up the textures a person can change the trim color fairly easily. and reuse the same texture for most of their nacelle variants. I still am going to recommend that bake their textures, though.
Here's a texture "guide" that will be part of the PSD that is to be released. There are pre-made areas that people can map to consistently, so this way a person using this kit can use a texture made by me, or by KF, or by whoever. Then if they need to there are open areas that they can make their own additions with, if need be.
(http://img242.imageshack.us/img242/2443/lnguide.jpg)
-
Looking good; cant wait
-
Well, I found a solution to a problem that I felt coming a little while back - it has to do with the alignment of UVWs. If you have the front of Nacelle A, the middle of Nacelle B, and the end of Nacelle F - you want the UVs of those to be aligned as best as humanly possible. The way that Max handles UVs its a little harder than you'd think. But, I have a solution. Included in all the nacelles that I will be released is a single plane object use to align the UVs. I'll post a video on how it works in a bit.
-
Here's a bit of the workflow that I've had to come up with when working with these parts.
[youtube]JVhlGnWOpfM[/youtube]
[youtube]a421aHVQS8g[/youtube]
-
So I started coming up with a naming convention for all the parts that might come about. This got me started thinking back a system of standards we might want to impliment towards this project.
I started doing a video about it, and after about 10 takes I got frustrated. So off to take a shower and I will try again.
-
Okay, made the video that I'm finally happy with. It goes into detail as to a naming convention and gives a quick glaze over on whywe would need a standard for this project in the first place. I will be playing with my wiki tonight to make room for bashkit documentation.
[youtube]UYac8CNpyjU[/youtube]
(may not be done processing yet)
Also on my mind is a video showing the complete evolution from template to final nacelle.
-
What, no flames?
-
I don't see a reason to flame but its a bit much to keep straight in the head. I get the gist of it. One thing is for sure at some point you will need to write it down so we can all remeber it.
-
Well, a lot of these thoughts are coming to me one after another. Keeping them straight in my own head is a little daunting.
As I get further along in the system I'll be making more concise and less ranty videos giving explinations and procedures. Furthermore my wiki will be updated to include all sorts of documentation for this project.
I know it seems slapdash at the moment (and truth be told, it is) but its slowly coming together :)
-
Did I get that right that one nacelle has 3800 polys? Heh, and using 2048x texture maps... lol. U'd need a super computer to run that thing in the game engine. Are u guys smoking crack?
-
Did I get that right that one nacelle has 3800 polys? Heh, and using 2048x texture maps... lol. U'd need a super computer to run that thing in the game engine. Are u guys smoking crack?
Better listening would have led you to find out that was the connie. secondly.... you would just need my computer to play with that ;)
-
I don't think the engine is 3800 polies, and textrures can be resized to match PC proformanc but the bigger they start out the better as te easier it is do do good looking details.
-
The entire connie was 3866 and I'm using 1024x textures.
-
Oh thats perfect! It got LOD's?
-
Not yet - One step at a time.
I haven't really thought all that hard about how to add LODs to the Bash kit, yet, but I'd like to.
-
So, what do you all think about adding required LODs to the standards of part-making for the bash kit? I can create a method but I'd like feed back.
-
Truthfully,
I think it would be a bad idea as the purpose is more or less to kitbash parts to make models. if the sections you make have LODs and the all the parts are not from this project then you will have parts of ships flying in the distance from kitbashers. The other reason is you are already making a complicated path to make mapping work adding this level is not really needed. not to mention the files for everything start to grow impractically large
-
I see your point - Honestly, my idea for a quick LOD workflow ended up being very very unweildy and impractical.
Another thing I can think of is to create the LOD templates, offer them to people who want to go through the effort and let people make LODs for parts they make if they so desire, but then we have a problem with some parts have LODs and some don't.... Is it better to have an all or nothing or is it better to have something better than nothing?
-
You are looking at all or nothing,
1 not all programs (milkshape) can work with LOD files.
2 if it LOD works, if they use outside peices the ships will be seen only as peices inside the game at a distance
3 not sure if a partial model is exportable
4 LODs require textures, normally at reduced size and resolution to be effective, this greatly increases the file size for each part
So well it is a nice idea it is not practical and would add needless complexity to your project, which is already complex. Best bet, if it can be done, templates work for those that will go the extra mile, most will not as it adds extra work and will not be useful moving ships from one game to the next.
So if it were me I would worry about the about the parts and making them interchangable. Once that is finished then look at templates.
-
I need someone who knows a bit more about the Nacelle Designations than I do. I know the canon Refit Connie nacelle is called the LN-64 by FASA and other lore. Are there any more generally accepted Fanon designations for other nacelles (ie: what is on the Constellation, what the funky ones the Ascension or whatever are called).
-
There is som info around for TMP stuff but nothing that is all inclusive. For example the LN-64 stands for Leeding Necelle model 64 and is the manufactuers name not the starfleet componet name. To get a unified system you will really need to make your own thing up. Just rememeber KISS.
-
I've seen a bunch of different designations around: LN-64, LN-72, LN-68, LN-66. That's fine if they are the company designation and not a starfleet one - better to use something established than have a completely arbitrary system (granted, arbitrary designations are going to come up, but they will be based on the aforementioned established system). The problem is that i don't know what the LN-66 is supposed to be, or the LN-72, etc.
-
The rest of these come from Todd Gunther's Ships of the Starfleet book. The cover the different Necelle veriants mostly for Constution class veriations. My copy is in storage but there is some fan stuff based on that book here http://www.cygnus-x1.net/links/lcars/index.html
The stuff is at the bottom of the blueprints section.
-
New video on the way: This one detailing how I made a completed nacelle from the "Template" pieces that you saw before.
-
Here's the video, in six parts.
[youtube]e685M7UJjd8[/youtube]
[youtube]mFlDGmJn-YU[/youtube]
[youtube]thtK04Oqtn0[/youtube]
[youtube]bz-iJ_UrU5c[/youtube]
[youtube]pJfX_meeJ8k[/youtube]
[youtube]55aYCsheYls[/youtube]
Something of note: when I say that the vertex count on the seams are important, I also mean to say that the placement of those vertices ought not be changed as part of the compatibility thing.
-
Very nice. thanks
-
Can I interupt and say I think its a great idea and I like what your doing. can I have your plugin thingy for your modelling tools on that floating window to the left :crazy2:
Ya dont get if ya dont ask :D
-
It's not mine. It's called Polyboost v4.1.
-
I'm moving on from nacelles to saucers. So far I have four saucers solidly in mind: Standard Enterprise, A saucer with a nacelle cut into the ventral side of it (http://www.inpayne.com/models/uss-montefusco.html), the Miranda saucer, and the Star League saucer (with the extra deck). This doesn't include saucers like the Excelsior, etc, yet. If anyone has more suggestions for more saucer variants they'd like to see, let's hear it.
-
I like this one too
-
I think we can arrange that :)
-
(http://img31.imageshack.us/img31/4536/underdeflector.jpg)
-
I like this one too
That's my Mars Class kitbash!! :-D Glad you liked it.
-
This is probably going to turn into a video blog
[youtube]CR_mcICztTs[/youtube]
-
You are putting allot of thought and work into this, and your ideas are excellent, the quality of work is great. I hope your not wasting your time though mate. Either way, good luck with it :)
-
I don't think you can get the different sizes on 1 texture but you dould try somthing like 512X512 panals for the differnt sections and let the basher put them together to make model specific 1024X1024 textures. That way you just swap out the panal for the different scale saucer or hull segment as needed.
-
I do have one solution in mind for the saucers. I'm working out the bugs as we speak. If I have time tonight I'll post an example of my thought process. If not tonight, then tomorrow.
-
The only problem I can see with it using one texture would be warping and streching issues in the none regular shaped areas
Even then model shading/smoothing might become a issue if you move it to a different texture sheet. so well you can easily make swapable parts other areas will accumulate errors that the modeller will have to know how to fix and make replacement textures for
-
Not sure if I follow what you mean, GAFY
-
I'm moving on from nacelles to saucers. So far I have four saucers solidly in mind: Standard Enterprise, A saucer with a nacelle cut into the ventral side of it ([url]http://www.inpayne.com/models/uss-montefusco.html[/url]), the Miranda saucer, and the Star League saucer (with the extra deck). This doesn't include saucers like the Excelsior, etc, yet. If anyone has more suggestions for more saucer variants they'd like to see, let's hear it.
Three suggestions actually.
a) FCX saucer (pretty please). Some people don't like them, but there are kitbashes that use 'em.
b) FCVF (fast cruiser), also pretty please. ;) http://starfleetcommand3.filefront.com/screenshots/File/31429/1
c) Something for a medical ship like the Olympic (Pasteur) and/or Daedeles. Not everyone will be doing TNG. ;)
Suggestions, take 'em or leave 'em..
-
Oh god - not that F-CF >.< that thing is so ugly. I'm going to leave that one for another part contributer to deal with :-/
FCX saucer is doable - but I'll leave that for when I start making the Excel parts.
Sphericals are easy (mostly), I'll see what I can do about those :)
-
Oh god - not that F-CF >.< that thing is so ugly. I'm going to leave that one for another part contributer to deal with :-/
Ugly yes, but here's a prime chance to make sure that anything going forward has a premade saucer that isn't. That's why I chose it.. the Fast Cruisers almost have an Intrepid type styling that you don't see on even Lost Era that much.. and if someone wants to recreate something like a TOS or TMP era Voyager, they'll need something like this hull to do it. ;)
Personal preference is that we wouldn't see many of these, but I can see where someone wants to build an updated Ranger (or Ranger itself) and they'd need something like this. All in all, your call.. just trying to put in some requests for differently shaped hulls to maximize some of the capabilities of the kitbashes, that's all..
-
I'll see about coming up with a version that doesn't make my stomach go all queezy whenever I see it.
-
I'll see about coming up with a version that doesn't make my stomach go all queezy whenever I see it.
Super, that's all I'm asking. :D
Again, look less at the "flat iron" idea on the one I pointed to, and look more towards an arrowhead or Intrepid as I think that's more the way to go. Streamlined, clean, smooth. :)
-
A decision has been made regarding the mapping of saucers. Right now I have four different saucers: the 100% (ie: the one the size of the enterprise's saucer), the 150% (the one you find on the star league), the 200%, and the 50% (like on the Okinawa).
This is my "Beta" version of the mapping"
(http://img716.imageshack.us/img716/6076/saucermapping.jpg)
- Blue = 200%
- Green = 150%
- Yellow = 100%
- Red = 50%
Right now they are all mapped so they use a 1024x256 texture. That was done so that sizes of details are uniform. However, I have decided to split it up properly. They will now each take up the maximum amount of room possible on different sizes textures. However, the scale between the different saucers will remain uniform. If this doesn't make sense to you - simply trust me.
-
Question.
For Battleships, would a texture that is 2048x512 be ridiculous? I know I have no problems running such sized maps (I've run 4x4096x4096 before), but I want to get a feel for what you guys think.
-
Well it depemds on how much biger the BB is then the DN. Mars is about 550m so its not much bigger then Star League; but Yamato is well over 800m. to need a texture that size the BB saucer would need to nearly twice the size of the DN saucer.
-
You are putting allot of thought and work into this, and your ideas are excellent, the quality of work is great. I hope your not wasting your time though mate. Either way, good luck with it :)
No one In the SFC community has put out as many videos Teaching others how to do stuff. :notworthy: :notworthy: :notworthy: :notworthy: FoaS_XC you are not waisting your time!!
-
Thanks kreeargh :) It's actually been a lot of fun to try and come up with this system.
Btw, guys, I am trying to come up with some sort of naming convention for saucers, secondary hulls, etc. The problem is coming up with something that will cover as many variants as possible while still telling people what they are working with. Much like I did for nacelles: LN series textures or pieces are compatible with other LN series pieces or textures, or PB series will be compatible with PB. I need something that will also indicate the same for saucers, bodies, pylons, etc.
BTW: Here's what I've got so far for the saucer's naming convention
"Scr-140-UPE-C"
Scr = Saucer
140 = Breadth of saucer (telling you the general size of the saucer, allows for smaller and bigger variants, like the Half-size on the Okinawa or the 150%-connie-sized on the Star League
UPE = "Utopia Planetia model E" (basically, a series name, kind of like the LN of the nacelles; UPEs will have common textures and parts; TOS Saucers might be called CYN for "Copurnicus Yards model N" or somesuch. Obviously, these are pretty made up, but I'm going from barebones here.)
C = Variant, for example, the Miranda might be called "C" for "Combined Hull" (ie: a combined primary and secondary hull functions), something like the Saladin might have "DS" for Deflector + Top-side Shuttlebay.
Thoughts?
-
Thanks kreeargh :) It's actually been a lot of fun to try and come up with this system.
Btw, guys, I am trying to come up with some sort of naming convention for saucers, secondary hulls, etc. The problem is coming up with something that will cover as many variants as possible while still telling people what they are working with. Much like I did for nacelles: LN series textures or pieces are compatible with other LN series pieces or textures, or PB series will be compatible with PB. I need something that will also indicate the same for saucers, bodies, pylons, etc.
BTW: Here's what I've got so far for the saucer's naming convention
"Scr-140-UPE-C"
Scr = Saucer
140 = Breadth of saucer (telling you the general size of the saucer, allows for smaller and bigger variants, like the Half-size on the Okinawa or the 150%-connie-sized on the Star League
UPE = "Utopia Planetia model E" (basically, a series name, kind of like the LN of the nacelles; UPEs will have common textures and parts; TOS Saucers might be called CYN for "Copurnicus Yards model N" or somesuch. Obviously, these are pretty made up, but I'm going from barebones here.)
C = Variant, for example, the Miranda might be called "C" for "Combined Hull" (ie: a combined primary and secondary hull functions), something like the Saladin might have "DS" for Deflector + Top-side Shuttlebay.
Thoughts?
I like the idea that the number matches the ship dia but what if you want to create a saucer with a 3 or 4 deck edge but keep the same
140 m dia I guess that is where the Letter series or put - Number for number of decks on the edge portion so
you could have the following
"Scr-140-4-UPE-C"
Just a suggestion
-
I would go with somthing that notes the first ship that used it like SCR-Ca-1700r-140. Miranda would be SCR-Cl-1864-140. Star League would be SCR-DN-2101r-210.
-
I considered the idea, but we all know how hairy and conflicting registries can get in a hurry - consider that FASA has one system, Canon has another, SFB has yet another, etc.
-
Sorry Bernard, I thought I replied to you but I never hit post and opened another tab
I think a deck count in the name would be superfluous. The way that the maps are set up, the saucer rims are in scale with each other. If you were to thicken the saucer by say, 200% - you'll have to stretch the UVs on the rims to suit. That means that the rim textures from other UPEs can't be used (you'll have to make a new model, say UPH; which is fine). A thickening of the saucer might be better of being a new Model - BUT: this means that the top and bottom textures can still be used on your UPH model.
But then again: consider the constellation: It uses the top and bottom (but not the rims) of the UPE. It has new rims that will need a new texture - so does that mean that it should be part of the UPE run or a new model (say, UPT). Same goes for the miranda. It uses all the same parts/textures as the UPE, but with a new additional part. Should it use
-
But then again: consider the constellation: It uses the top and bottom (but not the rims) of the UPE. It has new rims that will need a new texture - so does that mean that it should be part of the UPE run or a new model (say, UPT). Same goes for the miranda. It uses all the same parts/textures as the UPE, but with a new additional part. Should it use
Actually, the Constellation uses two dorsal sections of the Connie, one for dorsal and one for ventral.
-
Ah, correction noted. Thanks :)
-
I like the idea of this, will certainly make it easier for kitbashing, and if the textures are all mapped the same, it means that you know what textures you're looking for if you're swapping parts from eras.
So you're taking a CV-era saucer and mixing it with UPE parts, you know that you need to change those CV textures to UPE to have them mix smoothly... and vice versa. :)
No more phull1, FVCA-1 stuff.. just maybe shull-cvn1.bmp swapped for shull-upe1.bmp
-
Alright folks - bit of an update. I reworked the saucer rims texture: The primary reason for which is I wanted to expand the "dead space" between the different parts of the UVs. The reason for this is to allow areas of added UV data between layers. Consider the churchill. The aft quarter of the saucer is taller than the rest of the rim space. I want to be able to allow for that and any other sort of added doodads and what not.
Work today was a pain, and tomorrow will likely suck as well. You'll probably have to wait until Wednesday for the next major bit of information.
-
no paycheck no mod fund I can wait.
-
Indeed.
Actually, tonight I'm having a bout of insomia, so it looks like I'll be able to get some work done on it. I did go ahead and mess with the UVs of the saucers. I'm sure people will scream at me for wasted UV space, but it's a necessary evil. Give me a minute and I'll post a quick template to show what's going on in the texture.
-
(http://img529.imageshack.us/img529/22/saucerrimuvs.jpg)
Okay, here's what I've got for the texture templates. The Non-expansion quarters are where UVs lie on the standard (Connie) saucer. Like I said, I added spaces (expansion areas) for where you may want to add to the texture for your own custom saucer. A good example, again, is the churchill. With the thicker saucer in the rear of the saucer, you can add the UVs for that thicker part to the "Rear Quarter Expansion Area" for seamlessness. The texture size is now 1024x512 instead of 1024x256.
-
Here's the texture that I've made for the rims.
scr-140-UPE-rims
(http://img181.imageshack.us/img181/8164/scr140uperims.jpg)
EDIT: My mistake, I put a rim in the wrong place.
-
Looking good from here. Are you going to have rim RCS thrusters?
-
They are on the top and bottom textures. I was tempted to try for some that extend on to the rim, but I knew that I couldn't get the pixels to line up to my satisfaction. People are welcome to try to with the bashkit when its out, though.
-
Don't know if you need any more but I ran across thess on Drex files and thought they would make good reference pics.
-
Actually, if you have any good shots of the little sensor things that are on the Miranda (that is those little things cut into the front of the ledge, and their protrusions). They are much like the three units that are around the Connie Deflector, but I could use a few shots of the ones on the Miranda.
-
Here is the "Scr-140-UPED" Saucer ("D" is for added deflector). Like I said, I'll be using this particular saucer on ships like the Saladin and the Abbe, even my own miranda (even though its not canon). Furthermore, I think I like the idea of it being the saucer on the F-GSC.
(http://img87.imageshack.us/img87/2018/scr140uped.jpg)
-
WOW! That is some really nice work there fellas. :)
-
nice look there
ok here what I have
-
and the rest
-
Thank ye much :)
-
Looks kind of shelvie/greebling. :)
-
I was more interested in the round thingy.
-
glad to help
-
Okay,
Now that the eve/da flame-war seems to have died down some. Here's a list of what I need to get working.
- Talk to Bonk about the wiki (Sorry bonk, i know we were supposed to touch base last weekend)
- Bridge modules
- Bridge Decks (that hump in the middle of the saucer that the bridge lays on)
- Sensor Modules (saucer bottoms)
- Photon Torp modules (the connie torp deck and the miranda torp pod as examples)
- Nacelle struts
- Necks
- Secondary Hulls
- Preparation for release of existing part systems (documentation, a "rules of usage", etc)
- Videos explaining why I did certain things and how I recommend continuing with other things.
-
Any plans for small shuttle bay parts to put on the saucers?
-
Yup :)
-
Sweeet :D