pouët.net

Point sprites shader distance bla bla issue size

category: general [glöplog]
Pre script: Imagine the thread title as a few tags.

Script: I'm doing some sort of effect using point sprites in opengl, and point sprites size is defined in pixels. I've already normalized their size, but now I need to make it look smaller with the distance. I'm on a bad math weak, so I need so help on resizing the things with the distance :/

added on the 2009-01-23 01:30:12 by xernobyl xernobyl
reply point sprites troll useless tag mockery
point sprites necessary not, shaders you will want. emulated they are, so you know just.
added on the 2009-01-23 01:35:07 by xyz xyz
The melody is so simple, that you can fart it
if you are in opengl rendering mode, then "#version 120" add to the shader code.

also, to gl_PointSize you must write your particle size, probably 1/distance with a clamp() so it widely doesn't rise.

but instead of distance which involves a square root, the much cheaper eye space linear z you can use.
added on the 2009-01-23 01:53:02 by iq iq
BB Image
added on the 2009-01-23 03:08:12 by zoom zoom
Tiagro: this might help.
anyway, take a look at shader programming.!
added on the 2009-01-23 03:20:56 by xyz xyz
Scale = Projection._m11 / Output.Position.w * ViewportHeight / 2
added on the 2009-01-23 08:41:26 by iTeC iTeC
After posting my math skills came back momentarily and I ended up with
size/distance/tan(fov/2)
added on the 2009-01-23 21:00:39 by xernobyl xernobyl
Can anyone answer me why does everything gets so slow when I try using "gl_FragDepth" in a shader?
added on the 2009-01-24 20:41:37 by xernobyl xernobyl
Is it suposed to be simple to use textures to simulate depth?
From my testings
Code:gl_FragDepth = gl_FragCoord.z;

is what happens, but when I do it, everything is really slow, but shouldn't it be z/w, like
Code:gl_FragDepth = gl_FragCoord.z/gl_FragCoord.w;

?

And when I try sending the Z from the frag shader it doesn't work like I want it :(

Code:glReadMind(this);
Doesn't work either.
added on the 2009-01-25 04:29:01 by xernobyl xernobyl
Quote:
if you are in opengl rendering mode, then "#version 120" add to the shader code.

Shouldn't that be the default?
added on the 2009-01-25 04:32:19 by xernobyl xernobyl
Quote:
This document specifies version 1.20 of the OpenGL Shading Language. It requires __VERSION__ to be
120, and #version to accept 110 or 120.

From the first lines of the specification... maybe I should read those with more attention.
added on the 2009-01-25 04:38:07 by xernobyl xernobyl
Writing to gl_FragDepth kills early z cull. You won't notice a difference with a cube but if you have bigger scene then you'll definitely see huge slowdowns.
added on the 2009-01-25 08:19:08 by pommak pommak
this prod was using 2D sprites plus writing to gl_FragDepth to have correct 3D intersections. And it wasn't slow (not slow enough as to become my rendering bottleneck at least)

I did however have to stop using pointsprites because _that_ was making it slow (when combined with the gl_FragDepth). In the end I used quads -by glRects(-1,-1,1,1)-, and that was fast again! At the time my conclusion was it was some sort of driver problem (in nvidia). Hope that helps.
added on the 2009-01-25 14:11:46 by iq iq
So, using traditional billboards is faster than point sprites? :|
added on the 2009-01-25 22:50:20 by xernobyl xernobyl
If pointsprites are slower than calling glRect for every particle then that sounds like a colossal driver bug to me. Pointsprites probably use a different driver path which would account for the possibility of a performance difference.
there are/was more problems with pointsprites. max size is something that can be changed on driver/hw level.

that's the reason why i stopped using it. could perhaps be better nowdays.
added on the 2009-01-25 23:46:08 by pantaloon pantaloon
also, pointsprites are clipped based on their center, what gets very annoying cause you see them disappear in the borders of the screen. Regular billboards don't suffer from this, of course.
added on the 2009-01-26 04:25:12 by iq iq
I'm working with point sprites too (in d3d9) at the moment and this max size is really pissing me off. I wonder why it is implemented like that? On my new radeon card the max size is 150 pixels. Doesn't make sense with resolutions like 1900x1200 :(
pantaloon: yep, on most ati cards they have a max size of 256 pixels whereas nvidia has a much higher limit (if any) - so things look very different between different vendors cards.
added on the 2009-01-26 10:34:22 by smash smash
My main issue with pointsprites (using DX) is that when I turn on texturemapping, all of the texcoord-registers get overwritten with the same texture coordinate data, so I loose whatever interesting data I pass on from the vertex shader. The dx9-doc is very sparse on information about this feature. (grrr)

But I think that it is worthwhile considering pointsprites whenever you are trying to draw small billboards ("thick" points). We used it in our latest demo for photonsplatting and I am using them for some gpu-accelerated computation at the moment. I do believe they are faster, at least on my nvidia-card. (iq: did you check up on those statements recently? It sounds weird that you chose quads because of their speed..)
added on the 2009-01-26 10:42:48 by Hyde Hyde
pantaloon: pointsprites arent meant to be enormous billboards anyway - they should be thought of as points with a "slightly-bigger-than-zero" area.
added on the 2009-01-26 10:45:36 by Hyde Hyde
Hyde: When googling about hlsl & point sprites I found a forum post somewhere from you about the texture data getting overwritten :)

I don't have that problem myself though, I can pass depth in a 1 dimensional TEXCOORD1 without problems.
Rob: indeed! and wtf - it was back in 2006 :P I didn't realize it was that long ago, so perhaps things have changed.. At the time of writing that forum post I did however make absolutely certain that all of my texcoords got overwritten.
added on the 2009-01-26 10:54:10 by Hyde Hyde

login