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 .
Navis: sure you don't mean "DOF particle effect"? :)
Navis: Just tried it on a radeon 4870 and the FOV particle effect worked perfectly :)
![[self-ban]](https://content.pouet.net/avatars/intro.gif)
*DOF
indeed ;)
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..
that was 3 years ago anyway..
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)
(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)
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.
kusma: You remember I told you I wouldn't install Vista, right? ;)
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.
"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.
gloom, jar, don't worry, kusma is a gl man, and you don't need DX10/Vista to run geometry shaders in OpenGL \o/
iq: I think you're mistaken there, even though he does write OpenGL drivers (?) for a living, he's a DX-man at heart ;)
noooooooooooooooooooooooes!!! /o\
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.
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.
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.
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?
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 ;)
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.
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.
