New articles and demos

Humus said:
That kind of swizzling isn't allowed, this is what the compiler says:

(52): error X5202: (Third source param) Invalid source selector: .rgbb/xyzz. The only available source swizzles in this shader version are: .rgba/xyzw (same as not specifying swizzle), .r/x, .g/y, .b/z, .a/w, .gbra/yzxw, .brga/zxyw and .abgr/wzyx.
Click to expand...
A bit disappointing. And the compiler doesn't even recognize that it could use xyzw in this case, because of the write mask.

I figured that's impossible to reduce an iteration to two instructions without arbitrary swizzle. However, I found a way to put two iterations in 5 instructions:

def c1, 0.0, 2.0, -2.0, 0.0

// calculate (Xi² + Cx) and (Xi * Yi + Cy)
mad r1.xy, r0.x, r0, t0
// Xi+1 = -Yi² + (Xi² + Cx)
mad r0.x, r0.y, -r0.y, r1.x
// Yi+1 = 2 * (Xi * Yi + Cy) - Cy
// -Yi+1 = -2 * (Xi * Yi + Cy) + Cy
mad r0.yz, c1, r1.y, t0.wzyx

// Next iteration
// calculate (Xi² + Cx) and (Xi * Yi + Cy)
mad r1.xy, r0.x, r0, t0
// Xi+1 = Yi * (-Yi) + (Xi² + Cx)
// Yi+1 = Yi * Xi + (Xi² + Cx)
mad r0.xy, r0.y, r0.zxyw, r1

Again, t0.z must contain -Cy
 
ScreenShot01.jpg


As you can see, the corona is all over the pillars, though it shouldn't, right? Or at least it should not be as "round", as it is. So my question is that is there any easy way (or any way at all) to make those coronas more "realistic", kind of transforming with the geometry?

Sorry if I still don't explain it well enough, or if teh question is stupid! ;)
 
worm[Futuremark said:
]As you can see, the corona is all over the pillars, though it shouldn't, right?
Click to expand...

The corona effect is trying to model either the "in-camera" or "in-eye" effect of looking at a bright light source. It's a kind of lense-flare if you like. That being the case, it will appear in front of any geometry.

Or at least it should not be as "round", as it is. So my question is that is there any easy way (or any way at all) to make those coronas more "realistic", kind of transforming with the geometry?
Click to expand...

You can change the degree or even shape of the blooming depending on how much of the light source is visable, but the bloom itself shouldn't be occluded by geometry.
 
PSarge said:
The corona effect is trying to model either the "in-camera" or "in-eye" effect of looking at a bright light source. It's a kind of lense-flare if you like. That being the case, it will appear in front of any geometry.
Click to expand...
Well I have always thought the coronas to simulate the effect of "moist" or "fog" or similar, and not a lens-flare effect. ;) In the case of "moist" (or anything else that's making the air thick/creating an corona) then it should be modulated by the geometry. Right?

Real-Life example: If you look outside on a muggy evening, and look at the street lights, you most prolly see the corona. Now, move some object infront of the corona, and it starts to disapear, but accordingly to the object that occludes it. The corona doesn't "shine" as a round object infront of the object. The occluded part of the corona's form is determinded by the object.

Damn I must be the worst guy on the planet to explain things.. :cry:
 
You mean like the corona around the sun in Halo? You can see this by moving around in the 2nd level of Halo, and watching the sun through the trees... its glare assumes different shapes depending on what's in the way.
 
BoddoZerg said:
You mean like the corona around the sun in Halo? You can see this by moving around in the 2nd level of Halo, and watching the sun through the trees... its glare assumes different shapes depending on what's in the way.
Click to expand...
Well not quite that one either. The sun beams dazzling thru branches of trees is not the thing I mean, though I do like that effect. HALO had it done nicely, but COULD be done better! ;)
 
worm[Futuremark said:
]Well I have always thought the coronas to simulate the effect of "moist" or "fog" or similar, and not a lens-flare effect. ;) In the case of "moist" (or anything else that's making the air thick/creating an corona) then it should be modulated by the geometry. Right?
Click to expand...

Ahh, I understand what you mean. Yes, that would be a scattering of light around the lightsource, and so should be rendered at the same depth as the light-source. Then it would be occluded by geometry.

It all depends what it is you're trying to model.
 
PSarge said:
worm[Futuremark said:
]Well I have always thought the coronas to simulate the effect of "moist" or "fog" or similar, and not a lens-flare effect. ;) In the case of "moist" (or anything else that's making the air thick/creating an corona) then it should be modulated by the geometry. Right?
Click to expand...

Ahh, I understand what you mean. Yes, that would be a scattering of light around the lightsource, and so should be rendered at the same depth as the light-source. Then it would be occluded by geometry.

It all depends what it is you're trying to model.
Click to expand...
Great! :D But the question is, is it possible, and why has no one done it? Or does it eat up too much performance to be used in games?

I must say that I am looking forward to see Humus make a demo of it.. ;)

edit: of course with some Fragment level Phong illumination Lighting etc.. You know, something that has it all! ;)
 
Xmas said:
A bit disappointing. And the compiler doesn't even recognize that it could use xyzw in this case, because of the write mask.

I figured that's impossible to reduce an iteration to two instructions without arbitrary swizzle. However, I found a way to put two iterations in 5 instructions:

def c1, 0.0, 2.0, -2.0, 0.0

// calculate (Xi² + Cx) and (Xi * Yi + Cy)
mad r1.xy, r0.x, r0, t0
// Xi+1 = -Yi² + (Xi² + Cx)
mad r0.x, r0.y, -r0.y, r1.x
// Yi+1 = 2 * (Xi * Yi + Cy) - Cy
// -Yi+1 = -2 * (Xi * Yi + Cy) + Cy
mad r0.yz, c1, r1.y, t0.wzyx

// Next iteration
// calculate (Xi² + Cx) and (Xi * Yi + Cy)
mad r1.xy, r0.x, r0, t0
// Xi+1 = Yi * (-Yi) + (Xi² + Cx)
// Yi+1 = Yi * Xi + (Xi² + Cx)
mad r0.xy, r0.y, r0.zxyw, r1

Again, t0.z must contain -Cy
Click to expand...

What can I say, I wish I had the same level of patience and willingness to dig deep into swizzling and shuffling in order to maximize throughput. Tried it and it works. It allowed 23 iterations instead of the previous 19. Another slight improvement in detail. Now we only need more precision. :)
 
worm[Futuremark said:
]
Great! :D But the question is, is it possible, and why has no one done it? Or does it eat up too much performance to be used in games?
Click to expand...

It can be done with one "particle" but it has all the problems particles usually has with intersections.

It should be done with a volumetric fog effect.
Humus has a volumetric fog demo, so basicly all he should do is put those around lightsources.
 
Humus said:
Heh, we'll see about that. ;)
Click to expand...
:D I will keep refreshing your pages..

Hyp-X said:
It can be done with one "particle" but it has all the problems particles usually has with intersections.

It should be done with a volumetric fog effect.
Humus has a volumetric fog demo, so basicly all he should do is put those around lightsources.
Click to expand...
This sounds interesting.. But would the volumeric fog even work as the coronas do in Humus' demo? I mean get brighter as the viewer gets closer.
 
Humus said:
What can I say, I wish I had the same level of patience and willingness to dig deep into swizzling and shuffling in order to maximize throughput. Tried it and it works. It allowed 23 iterations instead of the previous 19. Another slight improvement in detail. Now we only need more precision. :)
Click to expand...
I just happen to have too much free time currently, and I found it quite challenging to squeeze the last bit out of the algorithm :D
I guess we'll never see compilers optimizing scalar operations like that. Well, with arbitrary swizzle such optimizations will be a lot easier. I'm quite surprised arbitrary swizzling could save another 12 cycles in this case.
 
Is Humus really the only one in here who is doing nice small demos for public view? I mean, now that he will start working for a big company, he will most prolly not be able to A) make as many of those nice demos as he has to work and B) might be that he won't be able demos that run on all hw.. ;)
 
worm[Futuremark said:
]B) might be that he won't be able demos that run on all hw.. ;)
Click to expand...

Like 3DMark03? Sorry I simply couldn't resist such a cheapshot .. just kidding Nickolas. :LOL:
 
You must log in or register to reply here.

Similar threads

Rys
Reopening Architecture and Products + rules and guidelines changes
3 4 5
Replies
90
Views
16K
Shifty Geezer
Shifty Geezer
A
ID@Xbox Summer Game Fest Demos [2021 June 15-21]
Replies
7
Views
2K
AzBat
A
Shortbread
Next-Generation NVMe SSD and I/O Technology [PC, PS5, XBSX|S]
105 106 107
Replies
2K
Views
217K
Karamazov
K
A
Dynamic framebuffer resolution
2 3
Replies
42
Views
17K
chris1515
C
Rys
Subscriptions and Donations
3 4 5
Replies
96
Views
32K
entity279
E
Back
Top