Logos (and I mean more than one)

[klauss]

Oh... yes... I have subunits now.
I almost forgot.
I'll see what can be done this weekend.

I'm thinking... clydesdale + escort?

[zaydana]

clyesdale and escort souds great. sidenote: i think the clyesdale should probably be facing with back at the right of the image, and front at the left.

[klauss]

Working on it still... sorry for the delay...

[zaydana]

*bump*

[klauss]

Oops... lost track of time... was working on planets, but I guess you can slap one on the background afterwards.

I'll see about getting the screenshot ASAP - I have all the tools now.

[zaydana]

*bump* again...

[dandandaman]

ya....klauss has kinda been snowed under, I'll remind him for thee when I see him

[zaydana]

okie dokey. If klauss can't do it thats fine, I'm sure i'll be able to figure out something. Also, I havn't even got a photoshop capable computer at the moment, so i'm no rush. Stupid faulty motherboards and long RMA times. meh.

[klauss]

Psst... over here.

Feel free to suggest different layouts

(Also... chuck... you may want to backup those - oh... and does it look big now or what?)

Sorry for:
1. The delay
2. The stats on the lower side... I realized when I had quite a few shots taken already
3. The background - I lost your background, and couldn't download it from your link. If you send it over, I may be able to take new screenshots with it..

[chuck_starchaser]

(Also... chuck... you may want to backup those

Just did; we're gonna have 50 gigs, not 5, btw.

Pretty, pretty shots. Can't decide between 4 and 10... well, definitely 4, but 10 has something sublime about the lights. Radiosity is baked, I imagine? But how did you get vertical streaks happening on the rectangular lights?
By the way, the texturing on the Clydesdale is superb.

[klauss]

Just did; we're gonna have 50 gigs, not 5, btw.

If you want, we can certainly do some cleanup. There must be deletable stuff in there. These shots are as .png instead of .jpg because Zay will need to be able to guage quality himself.

Radiosity is baked, I imagine?

Yes, and no... it's a mixture of factors, what gives the impression.
A) Those textures... can't remember if they're Howard's or Strangelet's, but they're pro for sure. They have a bit of "radiosity baking", or something that gives the impression.
B) There's a form of dynamic soft shadows, which in some cases becomes ambient occlusion - it's called "stochastic shadow sampling" or something like that - basically, throw a few dozen lights, and let the shadows do their thing - I think that scene has close to 100 lights. Hence the polycount (for shadow volumes). Usually, the engine limits the lights, but for the screenshots I disabled all limits
C) Prefiltered environment maps - it creates some sort accurate ambient lighting that is very pleasant. Take that, raise it to the Nth power, and that's how dynamic ambient occlusion will look like

But how did you get vertical streaks happening on the rectangular lights?

Ehm... I think those are z-artifacts

By the way, the texturing on the Clydesdale is superb.

Like it? I redid the specmap - the original was shameless.

[chuck_starchaser]

Just did; we're gonna have 50 gigs, not 5, btw.

If you want, we can certainly do some cleanup. There must be deletable stuff in there. These shots are as .png instead of .jpg because Zay will need to be able to guage quality himself.

Well, precisely the urgency for a cleanup is about to go away, going from 2 gigs space, suddenly to 50. I've uploaded Brad's 500 meg video tutorial again, in fact, though the switch won't happen until next week now, as I had to change packages; --the one I'd picked first, the 5 gig one, I hadn't noticed, only allowed 1 ftp account...

Radiosity is baked, I imagine?

Yes, and no... it's a mixture of factors, what gives the impression.
A) Those textures... can't remember if they're Howard's or Strangelet's, but they're pro for sure. They have a bit of "radiosity baking", or something that gives the impression.
B) There's a form of dynamic soft shadows, which in some cases becomes ambient occlusion - it's called "stochastic shadow sampling" or something like that - basically, throw a few dozen lights, and let the shadows do their thing - I think that scene has close to 100 lights. Hence the polycount (for shadow volumes). Usually, the engine limits the lights, but for the screenshots I disabled all limits
C) Prefiltered environment maps - it creates some sort accurate ambient lighting that is very pleasant. Take that, raise it to the Nth power, and that's how dynamic ambient occlusion will look like

Gosh, now I'm getting the idea... We *need* that, then. Even worth doubling texture sizes, if that's what it takes... How about using the standard pipeline? Say, for the two main objects, dynamic skyboxes, so that's 12 renderings, but at like 64x64 rez each...

But how did you get vertical streaks happening on the rectangular lights?

Ehm... I think those are z-artifacts

They look super-cool, tho. Any way we could intentionally exploit z-artifacts that way?

By the way, the texturing on the Clydesdale is superb.

Like it? I redid the specmap - the original was shameless.

Well, the panelling doesn't make a whole heap of sense, but the texture, overall, seems well composed, like grooves and paint and stains and specularity seem to be stacked in the right order or something It looks like a "healthy" texture, pretty 'believable'. Just needs a detail normal map...

[GAlex]

these SS are marvellous!

but the fps count is stuck to 1.0something. is it your pc or we all need a sup-r-sup-r-video-credit-cardto run the ogre version? (still haven't tried the svn code)

[klauss]

Gosh, now I'm getting the idea... We *need* that, then. Even worth doubling texture sizes, if that's what it takes... How about using the standard pipeline? Say, for the two main objects, dynamic skyboxes, so that's 12 renderings, but at like 64x64 rez each...

Something like that I was thinking about: using lower LODs, low-res, then filter.
The standard pipeline is out of the question, though... It's imperative that the rendering of the skyboxes use dynamic ambient occlusion themselves, to achieve the recursive effect.
I expect more trouble from filtering... the HDR thing does it and it's a big hit. Perhaps I can simplify filtering...

They look super-cool, tho. Any way we could intentionally exploit z-artifacts that way?

I don't think so. They're quite unpredictable when animated, and wouldn't look right at all.

Well, the panelling doesn't make a whole heap of sense, but the texture, overall, seems well composed, like grooves and paint and stains and specularity seem to be stacked in the right order or something

That wasn't me... but ya.

It looks like a "healthy" texture, pretty 'believable'. Just needs a detail normal map...

I was thinking just that when taking the screenshots

but the fps count is stuck to 1.0something. is it your pc or we all need a sup-r-sup-r-video-credit-cardto run the ogre version? (still haven't tried the svn code)

a) Read the polycount
b) Read my previous post - hundreds of lights = hundreds of passes. Expect more like 100-150FPS from the engine, but obviously less pretty lighting (not by much, though...).
c) Most of the slowdown is caused by stencil shadows, which are done mostly in software - and what's done on hardware is a killer just as well, raising fill rates to the sky and above. The engine, on release, will probably have shadows disabled ( for looks, but for speed )

[chuck_starchaser]

2 quick thoughts, Klauss:

1) Any way to trim the excess off stencil shadows? Say, fade them linearly with distance, and chop them off at the zero point...
Or, better yet: Join all the planes at a point some distance off (e.g. 8 times or 16 times the linear "size" of the unit projecting the shadows). I know you're gonna say "shadows expand with distance" ... well, yes and no, they outer penumbra expands, the inner shadow contracts, but over-all, who cares? We save half the vertices. Call it "Shadow Cucuruchos", if you will. Seriously, let me make a strong statement here: Shrinking and thinning shadows aren't just "better" than NO shadows at all; they are also more correct.

2) 'bout detail whatever... I was reading the old thread there, and it seems that the mapping is done using coordinate projection planes... Wouldn't it be easier to just multiply the p,q indexes being used to index into the regular texture, say by 16.0 modulo 1.0, and use the result to index the detail texture, detail normal map, or detail whatever?

EDIT:
3) Since your Global Illumination (TM) idea works by recursing in time, couldn't the filtering problem be solved similarly? Assuming there's a way to do a simple blur in the hardware (if not, read EDIT 2), you could make your boxes's side textures progressively blur in time by re-blurring them at each frame. Of course, this ignores input and would, by itself, converge to a flat color, BUT, you could trickle the input into them. The pseudocode formula, where T is texture, N is frame number, would be something along...

Code: Select all

Tout[N+1]=0.1*Tin[N] + 0.9*BasicBlurOf(Tout[N])

or

Code: Select all

Tout[N+1]=BasicBlurOf(0.1*Tin[N] + 0.9*Tout[N])

... whichever's more convenient. Tin is the input texture, the render target; and Tout the filtered texture.

EDIT2:
Allright, might as well be a pessimist and assume there is no explicit way to do a blur in hardware. No sweat: Recursive solution again: Have two sets of boxes. The smaller, raw box gets the input (rendering at say 32x32) The inner box is rendered from the outer box from the previous frame: each side, say 64x64 from a single billboard, that being the corresponding side in the lower res outer box. And the inner box is also cumulative, as per the formulas above or something along the lines.
The steps, at a given frame, would be, then, sort of like...
1) Scale down inner box side writing to outer box side (single billboard render, could be point-sampled or bilinealy filtered).
2) Filter outer box side (by scaling up) back to inner box side (single billboard render again, with bilinear filtering)
(First two steps are simply a way to achieve a blur step)
3) Render world to outer boxes (32x32).
4) Blend outer boxes scaled up onto inner boxes with, say, 0.1 blending factor.
(Last two steps to tricle in the input)

Additionally, you could jitter the angular alignment of the renders and between boxes at each frame, randomly or with some pattern, to loosen and spread the crap a bit.

Alternatively, if you're going to use per-vertex illumination, like we were talking, in the vertex shader, you could also recursively low-pass filter the input into them...

Before you ask, I had salmon steak for lunch.

[Privateer Ferrius]

Out of slightly-on-topic-curiosity, how does VS handle mipmapping exactly, if at all? And how would it handle it in the future with these changes?

[klauss]

@chuck: Interesting idea... I'll have to try that.
@ferrius: Doesn't. The hardware does. Basically, uses du/dv interpolations per-pixel to decide which mip level to use. Check the OpenGL specs for more specific formulae.

[chuck_starchaser]

Here's another one: How about setting a VS texture standard by which the top left corner of every texture contains the "detail" tile? Say the size of it could be fixed at 1/4 of x and 1/4 of y (1/16 th of the area). Something in the .bfxm or .mesh would indicate that the textures conform to this standard, if they do. And if they do, all textures have it: glow, specular, diffuse, mirror and normal map. Then, in the shader, we take the interpolated texture coords, multiply them by 16, modulo 0.25, read that and throw it in the mix. The advantage being, we don't occupy extra texture units, and we get delail glow, detail spec, etceteras, all at once, instead of piece-meal and having to specify "Texture17=..."
So, say for a 1k by 1k texture, the top-left 256x256 square is reserved for detail. The texture coords without premultiplication, taken modulo 0.25 would cause the detail to map 4 time across x and y, without adding any detail. With pre-mul by 16, the 256 width of the detail square maps to 16 pixels of the main texture, and adding 16 times more resolution at the bottom. I think that would make for a fairly well balanced scaling, in the sense that if the main texture were low-pass-filtered to half the sampling frequency, and the detail were high-pass-filtered at half the width, there'd still be 2-bits of spectral overlap

[klauss]

Two things:
a) Though it's an interesting thing to have a "detail zone" defined within textures, I don't think it's worth the hassle. The hassle being that it forces complex (relatively speaking) shaders because texcoord wrapping has to be performed manually (the only automatic wrapping is in the [0,1) range). So... I'd rather use the standard, separate-texture approach, to keep pixel shaders simple (and allow for... say... more lights to be computed).
b) We should continue this on its own thread.

[zaydana]

heres that background I was hoping to get it on...

http://img111.imageshack.us/img111/669/ ... ull4af.jpg

[klauss]

Great - I'll get it in, and take some new shots sometime soon - probably this weekend, I have much work + a test during the week.

[klauss]

Look here Zay!

Very pretty background
I took the liberty to manually add sunflares to a couple shots, otherwise the sun looked awful. Don't worry, I did it just the way the engine would do it, and with vegastrike's flare even, so they're representative of the final ingame look (no kidding).

Sorry for the blurred and enlarged look of it, though - it seems it lacked the resolution for a starry background (one reason to draw stars separately) - I didn't think it would be a big problem, though, since I imagine you'll shrink the hell out of it - but, if you need it so, let me know and I can reorganize the cubemap to make it a little bit better (just pick the shot you want me to recreate... I wouldn't want to recreate them all).

IMHO, the ~27 batch is the best for the website.

Oh... and you may need to rotate/crop them a bit.

BTW: Those you don't use for the heading, I see as great for the "random backgrounds" we talked about, if you want to give that a try.

I'll be home all day tomorrow (today? - monday), so whatever you need, if you tell me soon, I'll be able to do it quickly.

Good luck, and I look forward to seeing it put to good use

PS: I'm still uploading, and it may take a goodly while to finish, since this connections seems slow today (2KB/s), and it's like 50MB that I have to upload. Luckily, I can leave it all night if I need to

[zaydana]

Whoa, they're awesome.

17 and 22 are my favourite for the purposes of a header... but 13 would be awesome too if it was zoomed out just a tiny bit more so the ship ended before the top left corner.

I think i'll end up making the background transparent anyway and leaving the ship, that way I can get the background just how I want it :-p, and the ship keeps its reflected colours. It looks great in those pictures anyways, but the cube is probably a bit too distinct.

As for random backgrounds... what if we were to do random headers instead? That way, the header would cycle between 17, 22 and a modified 13 - and we could add any new ones to the mix too.

It might be a while before I actually get around to doing the design now... I'm probably only really going to be able to work on it during weekends. I still want to do it though, and hopefully it'll get done pretty soon.

[zaydana]

Just another little idea I got, dunno if you guys like it or not. If we had something like pic 13, but it was a flash animation, that would be awesome. That way... you could have the big fleet moving through space, just like in the movies You could also have the stars getting slightly brighter and dimmer through the use of a levels filter placed over the background layer. I guess the fleet would consist of a clyesdale and a few smaller ships every minute, then in between those you'd still have smaller fighters flying through. It would give the impression of a massive fleet of freighters and small fighters. Then again tho, some people don't like flash. The compromise would be to keep the background, and lay the flash animation over the top, so it wouldn't look ugly even if people didn't have flash.

Come to think of it... that stars thing could be a rather cool thing to do to VS itself - a levels filter on the background cube's texture which randomly makes the stars a bit brighter / darker. It would liven up the background a lot... even if only very subtley.

[klauss]

BTW, sith ~27 batch I actually meant 31 & 32 - I renumbered them before uploading, I thought I had numbered 31 as 27, but obviously I was wrong (oops).

I'll see what I can do with 13. Also, if I know you'll scrap the background, I have more freedom in picking an angle with good reflections, so it may turn out a lot nicer interesting in the end