Re: Shipyard

Here, various developers can tell you all about what they're up to, so you can yell at them for being idiots. "... and there was a great rejoicing."
Message
Author
User avatar
eleazar
Design & Graphics Lead Emeritus
Posts: 3858
Joined: Sat Sep 23, 2006 7:09 pm
Location: USA — midwest

Re: Shipyard

#1 Post by eleazar »

pd wrote:This is something I've been working on for a couple of days. It's still a rather early WIP, but I thought it might be a good idea to share this. It's (very) loosely based on one of Josh's concepts, so I'm not sure if it still qualifies as Gyisache.

Image

design notes:
  • compact shape - can take some hits but isn't too strong on the offensive side
    FTL engines at the back and maneuver engines at the sides - fast and agile
    curvy graphics = non-aggressive
    sensor array in the front(still needs some work) - those guys are supposed to be afraid and sheepish, right?
I still need to detail some parts and then decide for the cutline layout. I'll create a lowpoly version and bake out the normal bump maps afterwards.

Happy new year.

Looks very cool, but you mean "carrier", not "shipyard", right?

User avatar
pd
Graphics Lead Emeritus
Posts: 1924
Joined: Mon Mar 08, 2004 6:17 pm
Location: 52°16'N 10°31'E

Re: Shipyard

#2 Post by pd »

Oh, it's just the thread title - it will make more sense once more ships are added to the thread :)

There is no specific function intended for the ship(hull).

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Shipyard

#3 Post by Geoff the Medio »

About how big is this ship intended to be? The curves make it seem like it should be really huge (and advanced) but the jutting out panels on the bottom sides make me thin of landing struts... possibly because some of the details inside look like pistons on which they'd extend... and this makes it seem not much bigger than an medium-small airliner (say 120-seater).

User avatar
pd
Graphics Lead Emeritus
Posts: 1924
Joined: Mon Mar 08, 2004 6:17 pm
Location: 52°16'N 10°31'E

Re: Shipyard

#4 Post by pd »

It's supposed to be the small(est?) hull. I don't have a definite size in mind, but it's probably about 50m in length. Does this sound reasonable?

User avatar
eleazar
Design & Graphics Lead Emeritus
Posts: 3858
Joined: Sat Sep 23, 2006 7:09 pm
Location: USA — midwest

Re: Shipyard

#5 Post by eleazar »

Did i start this as a new thread? If so it was an accident.

User avatar
pd
Graphics Lead Emeritus
Posts: 1924
Joined: Mon Mar 08, 2004 6:17 pm
Location: 52°16'N 10°31'E

Re: Shipyard

#6 Post by pd »

Don't worry, I've split it to keep the main thread "clean". Comments go here.

User avatar
Josh
Graphics
Posts: 452
Joined: Mon Dec 31, 2007 10:49 am
Location: California, USA

Re: Shipyard

#7 Post by Josh »

It looks like you've got the 3D stuff under control, and it's quite impressive for the first ship. I understand you want to lay the groundwork before anybody else gets involved, so as to set a standard and make it easier for contributors to know what's expected of them, so do you want an assistant or would you prefer to take it from here?

User avatar
Tortanick
Creative Contributor
Posts: 576
Joined: Sat May 26, 2007 8:05 pm

Re: Shipyard

#8 Post by Tortanick »

I just saw your latest updates, its beautiful :)

If it no longer fits the Gyisache, the AEIOU would be happy to adopt it.

tempsanity
Space Krill
Posts: 3
Joined: Sun Jan 11, 2009 8:22 pm

Re: Shipyard

#9 Post by tempsanity »

Very nice. Keep up the good work mate.

User avatar
Bigjoe5
Designer and Programmer
Posts: 2058
Joined: Tue Aug 14, 2007 6:33 pm
Location: Orion

Re: Shipyard

#10 Post by Bigjoe5 »

The Trith fighter looks great - really professional. In fact, it's better than professional; it's professional minus deadlines. I'm looking forward to seeing the whole line of Trith ships.
Warning: Antarans in dimensional portal are closer than they appear.

User avatar
pd
Graphics Lead Emeritus
Posts: 1924
Joined: Mon Mar 08, 2004 6:17 pm
Location: 52°16'N 10°31'E

Re: Shipyard

#11 Post by pd »

Ha, thanks Bigjoe, it's funny, because I had a job interview today and it went extremely well. About a third of my portfolio I applied with, was freeOrion stuff.

I'll start the first big ship right after the fighter is completed. I'll also start building a physical model for a university project, so progress might be a little slower, but I'll try to keep it consistent.

tzlaine
Programming Lead Emeritus
Posts: 1092
Joined: Thu Jun 26, 2003 1:33 pm

Re: Shipyard

#12 Post by tzlaine »

The stuff in the shipyard is really shaping up! Some things to consider:

1) Can you commit the fighter model?

2) Have a look at this:
http://www.eveonline.com/devblog.asp?a=blog&bid=732
It's an EVE-Online Dev Blog about how they use their textures/materials system to provide a single model with lots of different looks. A lot of it doesn't apply to our use case, but it's still food for thought.

3) Do we need to add a decal layer to models? That would be the easiest way to add colored patterns like "player colors - variation {1,2}" from your recent post.

4) We have a glow pass, but we currently don't use it for ships. We currently only use the glow pass to make the star shine brightly. The glow pass is a fixed cost that we have to pay every frame right now. Adding glowing materials to a ship is therefore "free". I say this because, as cool as the glowing bits of your model are, if the glowing bits are occluded, they won't shine around the edge of the occluding object like the star does. I don't know if this is even an effect you want to use, I'm just reminding you it's there for you if you want it. Just to be clear -- I'm not talking about the glow texture we currently use for our ships. I'm talking about glow like we use for the star -- colors that "bloom" out into surrounding pixels.

5) How flexible is your exporting capability? I ask because right now, we use 4 textures (color, glow, normal, ans specular/gloss), but we only use a total of 11 channels in those images. (As an aside, we are currently ignoring the gloss channel too.) Modern video hardware stores everything as RGBA in video memory, so compressing these channels down to 3 RGBA textures would be better, and that would leave us one free channel for a decal map (as in #3 above). We'd need to add the player/empire color as a parameter to the shader, and it could use the map to determine where to apply the color. If I need to, I can write an ImageMagick script that will take our current texture set and create a packed one like I'm proposing. If it's possible for you to do at export-time, though, all the better.

6) The ships that you have been creating are probably too big. Instead of my scaling them down, could you scale the Guardian model down so that it looks reasonably-sized to you when you run with --test-3d-combat? Keep in mind that, even though it may not be technically possible, we'd like to shoot for hundreds/thousands of ships fighting in a single system at the same time. Try to keep the scale of future models with that in mind.

User avatar
pd
Graphics Lead Emeritus
Posts: 1924
Joined: Mon Mar 08, 2004 6:17 pm
Location: 52°16'N 10°31'E

Re: Shipyard

#13 Post by pd »

tzlaine wrote: 1) Can you commit the fighter model?
Yes, sure. Will do it first thing in the morning - in about 8 hours.

I'll also comment about the other points. Nice updates in SVN btw, can't wait to see it myself.

User avatar
pd
Graphics Lead Emeritus
Posts: 1924
Joined: Mon Mar 08, 2004 6:17 pm
Location: 52°16'N 10°31'E

Re: Shipyard

#14 Post by pd »

tzlaine wrote: 2) Have a look at this:
http://www.eveonline.com/devblog.asp?a=blog&bid=732
It's an EVE-Online Dev Blog about how they use their textures/materials system to provide a single model with lots of different looks. A lot of it doesn't apply to our use case, but it's still food for thought.
Thanks, very interesting. Good reference as well.
3) Do we need to add a decal layer to models? That would be the easiest way to add colored patterns like "player colors - variation {1,2}" from your recent post.
Yes, I think that would be the ideal way. Color texture rgb + decal pattern as alpha, the rest is done by code.
4) We have a glow pass, but we currently don't use it for ships. We currently only use the glow pass to make the star shine brightly. The glow pass is a fixed cost that we have to pay every frame right now. Adding glowing materials to a ship is therefore "free". I say this because, as cool as the glowing bits of your model are, if the glowing bits are occluded, they won't shine around the edge of the occluding object like the star does. I don't know if this is even an effect you want to use, I'm just reminding you it's there for you if you want it. Just to be clear -- I'm not talking about the glow texture we currently use for our ships. I'm talking about glow like we use for the star -- colors that "bloom" out into surrounding pixels.
We should definitely try it out! I did a mockup here. This should work even better with the updated glow maps. It's important to not overdo it though.
5) How flexible is your exporting capability? I ask because right now, we use 4 textures (color, glow, normal, ans specular/gloss), but we only use a total of 11 channels in those images. (As an aside, we are currently ignoring the gloss channel too.) Modern video hardware stores everything as RGBA in video memory, so compressing these channels down to 3 RGBA textures would be better, and that would leave us one free channel for a decal map (as in #3 above). We'd need to add the player/empire color as a parameter to the shader, and it could use the map to determine where to apply the color. If I need to, I can write an ImageMagick script that will take our current texture set and create a packed one like I'm proposing. If it's possible for you to do at export-time, though, all the better.
I can easily do it myself.

I would suggest something like this:
1. rgb -> diffuse red, diffuse green, diffuse blue; a -> decal
2. rgb -> normal x, normal y, normal depth; a -> specular
3. rgb -> glow red, glow green, glow blue; a -> gloss

We could by the way save 2 channels in the third map and maybe use those for something else(more decals?), if the the shader would take in a b/w image and use this to determine the intensity of the self-illumination, but take the color from the color map.

Then we could do something like this:

1. rgb -> diffuse red, diffuse green, diffuse blue; a -> specular
2. rgb -> normal x, normal y, normal depth; a -> gloss
3. rgb -> decal 1, decal 2, decal 3; a -> glow


6) The ships that you have been creating are probably too big. Instead of my scaling them down, could you scale the Guardian model down so that it looks reasonably-sized to you when you run with --test-3d-combat? Keep in mind that, even though it may not be technically possible, we'd like to shoot for hundreds/thousands of ships fighting in a single system at the same time. Try to keep the scale of future models with that in mind.
No problem, will do.

tzlaine
Programming Lead Emeritus
Posts: 1092
Joined: Thu Jun 26, 2003 1:33 pm

Re: Shipyard

#15 Post by tzlaine »

pd wrote:
5) How flexible is your exporting capability? I ask because right now, we use 4 textures (color, glow, normal, ans specular/gloss), but we only use a total of 11 channels in those images. (As an aside, we are currently ignoring the gloss channel too.) Modern video hardware stores everything as RGBA in video memory, so compressing these channels down to 3 RGBA textures would be better, and that would leave us one free channel for a decal map (as in #3 above). We'd need to add the player/empire color as a parameter to the shader, and it could use the map to determine where to apply the color. If I need to, I can write an ImageMagick script that will take our current texture set and create a packed one like I'm proposing. If it's possible for you to do at export-time, though, all the better.
I can easily do it myself.

I would suggest something like this:
1. rgb -> diffuse red, diffuse green, diffuse blue; a -> decal
2. rgb -> normal x, normal y, normal depth; a -> specular
3. rgb -> glow red, glow green, glow blue; a -> gloss

We could by the way save 2 channels in the third map and maybe use those for something else(more decals?), if the the shader would take in a b/w image and use this to determine the intensity of the self-illumination, but take the color from the color map.

Then we could do something like this:

1. rgb -> diffuse red, diffuse green, diffuse blue; a -> specular
2. rgb -> normal x, normal y, normal depth; a -> gloss
3. rgb -> decal 1, decal 2, decal 3; a -> glow
Ok, you might have lost me here. What do you mean by "a b/w image and use this to determine the intensity of the self-illumination, but take the color from the color map"? Does this mean that the glow color is taken to be (diffuse red, diffuse green, diffuse blue)? If that's the case, is the glow channel just 0.0 or 1.0? If not, how do values in between get combined with (diffuse red, diffuse green, diffuse blue) to get the glow color?

That issue aside, I like where your second option above is going. I especially like it that you can specify one texture that has all the varying stuff in it (#3).

Also, we currently use the same value for gloss as for specular. It looks good to me as-is; is it sufficient? If so, it gives us one more channel to work with, and would allow us to put the glow color back in as a 3-channel color that could change from variant to variant:

1. rgb -> diffuse red, diffuse green, diffuse blue; a -> specular/gloss
2. rgb -> normal x, normal y, normal depth; a-> [unused (or decal 2?)]
3. rgb -> glow 1, glow 2, glow 3; a -> decal

The reason I like this is that, unless we really need a second decal channel -- which at this point I don't think we will -- we can vary the decals and the glow color, just like in your mockups in the Shipyard thread, by swapping in a single texture. The only hole in this plan is that the glowing bits will not illuminate any other nearby parts of the model; this may be a deal-breaker by itself.

Post Reply