(This sounds sort similar to parts of my thesis work. :)

Oliver Kutter wrote:

Now I want to compute the whole particle system with the shader and don't write it back to the geometry. In the 1st pass I want to get the current position of the particle and compute its new position with the shader procedure, that I already have (I decoded the new position as the color). Then, in the 2nd pass, I want to assign the new vertex position computed by the fragment shader of the 1st pass. And with the fragment shader of the 2nd I set the texture and the color of the particle.

I think, it could be possible to compute the whole thing in one pass, but I don't know how?

Given support for MRT (multiple render targets, which would mean using OSGPassiveWindow for now, methinks) you could use the vertex program to read from the particle state texture(s) and only simply to transform each point into screen space, then do rendering _and_ calculate/update the state-texture(s) for the next frame in the fragment program.

My problem is (I did read this somewhere), that vertex shader has no texture access and is not as fast as a fragment shader. Or am I wrong?

Newer cards do support texture access in vertex programs (with some restrictions). You're right in that vertex programs are not as fast as fragments (mainly due to there being roughly only half the number of pipes and a more complex data and operations), but they're nevertheless quite fast and certainly faster than using the CPU.

Best regards,
/Marcus


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users

Reply via email to