Page 1 of 3

Re: Shipyard

Posted: Fri Jan 02, 2009 7:27 am
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?

Re: Shipyard

Posted: Fri Jan 02, 2009 10:18 am
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).

Re: Shipyard

Posted: Thu Jan 08, 2009 10:12 am
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).

Re: Shipyard

Posted: Thu Jan 08, 2009 2:56 pm
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?

Re: Shipyard

Posted: Thu Jan 08, 2009 9:13 pm
by eleazar
Did i start this as a new thread? If so it was an accident.

Re: Shipyard

Posted: Fri Jan 09, 2009 6:34 am
by pd
Don't worry, I've split it to keep the main thread "clean". Comments go here.

Re: Shipyard

Posted: Fri Jan 09, 2009 6:37 am
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?

Re: Shipyard

Posted: Mon Jan 12, 2009 11:23 am
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.

Re: Shipyard

Posted: Mon Jan 12, 2009 12:54 pm
by tempsanity
Very nice. Keep up the good work mate.

Re: Shipyard

Posted: Mon Feb 22, 2010 4:20 pm
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.

Re: Shipyard

Posted: Mon Feb 22, 2010 6:31 pm
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.

Re: Shipyard

Posted: Thu Apr 08, 2010 5:20 pm
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.

Re: Shipyard

Posted: Fri Apr 09, 2010 1:51 am
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.

Re: Shipyard

Posted: Sun Apr 11, 2010 2:10 am
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.

Re: Shipyard

Posted: Sun Apr 11, 2010 4:01 am
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.