pouët.net

Point sprites shader distance bla bla issue size

category: general [glöplog]
Hyde: yes, in 2006 I got that too and it drove me nuts until I found it. As far as I know, the FOV particle effect in animal attraction (similar to the one in we cell) still doesn't work ok on ATIs .
added on the 2009-01-26 12:08:06 by Navis Navis
Navis: sure you don't mean "DOF particle effect"? :)
added on the 2009-01-26 12:12:49 by kusma kusma
Navis: Just tried it on a radeon 4870 and the FOV particle effect worked perfectly :)
*DOF

indeed ;)
yes sorry DOF. At the party place (in gathering 2006) and I think on the recorded video that is on scene.org you get many particles appearing disappering in random. That doesn't happen on nvidia cards.

that was 3 years ago anyway..
added on the 2009-01-26 12:41:10 by Navis Navis
I guess geometry shaders is the thing today anyway. Memory and bandwidth consumption of one point, and no clipping and size limitations, like in billboarded quads.

(hyde, no, I didn't try again since may 2007 at least. But the clipping problem was enough for me to go for the quads anyway)
added on the 2009-01-26 12:46:38 by iq iq
I don't notice this clipping problem either. Maybe it's not a problem with d3d9.
iq: Yepyep, in 2009 we use the geometry shader for our particles.
added on the 2009-01-26 12:50:37 by kusma kusma
kusma: You remember I told you I wouldn't install Vista, right? ;)
added on the 2009-01-26 13:03:50 by gloom gloom
oh yeah... guys, please read particle rendering revisited.

"Note that for Direct3D 10 you can also render from your particle data stream with D3D10_PRIMITIVE_TOPOLOGY_POINTLIST, and perform quad expansion with geometry shader.

This in theory should somewhat speed up vertex processing part, but in practice I have very bad experience with geometry shaders on NVidia cards performance-wise. "

And not everybody wants to use DX10.
added on the 2009-01-26 13:03:54 by arm1n arm1n
gloom, jar, don't worry, kusma is a gl man, and you don't need DX10/Vista to run geometry shaders in OpenGL \o/
added on the 2009-01-26 13:06:05 by iq iq
iq: I think you're mistaken there, even though he does write OpenGL drivers (?) for a living, he's a DX-man at heart ;)
added on the 2009-01-26 13:10:18 by gloom gloom
noooooooooooooooooooooooes!!! /o\
added on the 2009-01-26 13:11:00 by iq iq
where i use billboards i use instancing to reduce the vertex count, of course.
i believe on gl you can specify whether each texcoord stream is passed through or replaced with pointsprite coords, which is nice. shame it doesnt work on dx9.
added on the 2009-01-26 13:24:02 by smash smash
Smash: I am worried now. I pass the depth in TEXCOORD1 without problems.. but maybe it only works with ATI drivers?
rob: try ref-device. I can't remember with 100% certainty if I that myself, but at least it did under no circumstance fly on my hardware back then.
added on the 2009-01-26 13:42:41 by Hyde Hyde
Hyde: seems to work with D3DDEVTYPE_REF as well... maybe it only works with vectors with only 1 component?
now that would be... strange. You're sure D3DRS_POINTSPRITEENABLE == TRUE when executing those shaders?
added on the 2009-01-26 13:53:52 by Hyde Hyde
Code:pyramid->SetRenderState(D3DRS_POINTSPRITEENABLE, true);


Yep :)

I assume otherwise the whole point sprite thing wouldn't work.

I use vs & ps 3.0... maybe that's the difference?
I tried with false now and nothing was rendered. So yes, it's set to true alright :)
my experience with this stems from the ps2.0 days. Now, if you could find some documentation for this behaviour, it would be nice ;)
added on the 2009-01-26 13:59:50 by Hyde Hyde
Please ignore the current hardcoded values...

Code: struct VS_OUTPUT { float4 Position : POSITION; float4 DiffuseColor : COLOR; float2 TexCoord : TEXCOORD0; float Depth : TEXCOORD1; float PointSize : PSIZE; }; float4x4 matrixWorldViewProjection : register(c0); // World * View * Projection float4x4 matrixWorldView : register(c4); // World * View float4x4 matrixWorld : register(c8); // World float4x4 matrixView : register(c12); // View float4x4 matrixProjection : register(c16); // Projection VS_OUTPUT Main(float4 vPos : POSITION, float4 diffuseColor : COLOR) { VS_OUTPUT output; output.Position = mul(vPos, matrixWorldViewProjection); output.DiffuseColor = diffuseColor; output.TexCoord = float2(0, 0); output.PointSize = (matrixProjection[0][0] / output.Position.w) * (720.f / 2.f) * 0.5f; output.Depth = (mul(vPos, matrixWorldView).z - 1.f) / (30.f - 1.f); return output; }
Hyde: I have been googling for 10 minutes now but I am afraid no new information about this behavior appeared since 2006... Point sprites are very badly documented, as you know, especially when used with shaders.
people shun them like rabies. poor things.
added on the 2009-01-26 14:20:43 by Hyde Hyde
Quote:
Hyde: I have been googling for 10 minutes now but I am afraid no new information about this behavior appeared since 2006... Point sprites are very badly documented, as you know, especially when used with shaders.

I agree.

Now, whatabout writing to the depthbuffer?
I have something like:
z = gl_Position.z; in the vertex shader
and gl_DepthCoord = z-texture*scale/(farplane-nearplane); in the fragment shader, and that doesn't work. Using just gl_DepthCoord = z; doesn't work either, so I think that my main problem is understanding wtf should I write on the depth buffer.
added on the 2009-01-26 14:27:01 by xernobyl xernobyl

login