pouët.net

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 :/

reply point sprites troll useless tag mockery

point sprites necessary not, shaders you will want. emulated they are, so you know just.

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.

Tiagro: this might help.
anyway, take a look at shader programming.!

Scale = Projection._m11 / Output.Position.w * ViewportHeight / 2

After posting my math skills came back momentarily and I ended up with
size/distance/tan(fov/2)

Can anyone answer me why does everything gets so slow when I try using "gl_FragDepth" in a shader?

Is it suposed to be simple to use textures to simulate depth?
From my testings

is what happens, but when I do it, everything is really slow, but shouldn't it be z/w, like

?

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

Doesn't work either.

Shouldn't that be the default?

From the first lines of the specification... maybe I should read those with more attention.

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.

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.

So, using traditional billboards is faster than point sprites? :|

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.

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.

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.

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..)

pantaloon: pointsprites arent meant to be enormous billboards anyway - they should be thought of as points with a "slightly-bigger-than-zero" area.

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.