ok… i read through the new specs from nvidia with vp1_1, ts3 etc…
i got most of it… i don’t get render_to_texture stuff cause i never worked with it (only copysubimage on the screenbuffer, no pbuffers etc used…) but i’ll get it as soon as there are examples out i guess… (i know what the idea is of render_to_texture, thought )
the new ts3 i got most of it, means the projective shaders are simple to understand… the 1d_dp3_texture lookup is a simple but very usefull thing,too… the rest i guess i’ve to wait for the nice powerpointpresentation with the visual way to follow what the instruction does i guess those dp3_depth stuff is for the “z correct bump mapping”…
but my real problem is rather simple
whats the use of vp1_1 RCC?!
it is exactly the same pseudocode as the RCP instruction (wich i never needed anyways but thats another topic… it has to be in, sure…)
except the clamping between 1.884467e+019 and 5.42101e-020 for positive values and the negative ones of it for negative values.
whats the use of clamping those values to these ranges? where can i use this/where do i need this? the precision is the same as RCP (at least, its written to be the same…) and so there is no other difference…
oh, and thanks for the DPH… finally its there… the SUB and ABS are nicer to write, too…
two days before the spec whas out i said to my friend hm… if z would be clamped for the shadow-volumes we could get perfect shadow-volumes without big stress at all… two days after the spec is out and this extension is in… too cool… thanks alot
now how about GL_NV_depth_repeat?
Originally posted by davepermen: i got most of it… i don’t get render_to_texture stuff cause i never worked with it (only copysubimage on the screenbuffer, no pbuffers etc used…) but i’ll get it as soon as there are examples out i guess… (i know what the idea is of render_to_texture, thought )
I have an example with source on my homepage (second from top) which uses WGL_ARB_render_texture. http://hem.passagen.se/emiper/3d.html
I’ve packed it into a nice little class that makes it very easy to use.
hm there where bugs with it? cool, did not knew… thanks for the info, cass…
yeah i’m very happy with the new extensions…
i just wonder how you got rcc into gf3 afterwards i mean, the rest is simple… even the dph can be done with 2 instrs…
so rcc is simply the same as rcp but makes sure that every division results in a number and 1/0 = infinite… as it should be…
so if i need one time rcp i’ll use rcc…
one thing left… what about an GL_NV_incr_frontface_decr_backface extension? would make it possible to do the stencil-stuff directly in 1 pass… no need for generating the volumes twice in the vp…
you could call it GL_NV_count_shadow for example…
but for the rest, those new exts are good “bugfixes” of what the gf3 lacked… espencially the texshaders do look promising…
there are several “bugs” left, but i can wait for ogl2 for them
hey humus. i just read your code and have to say its awesome! really nice done texture-classes, and mostly i like the imaging-stuff you have, really great done. the last thing you should do in your image-process-functions is the wellknown FourierTransform… for big filters that would be very nice to process the image…
about the GL_NV_count_shadow…
i guess i found a way to not transform the geometry twice (and doing the whole shadow-volume generation twice in the vp1_1…
my idea:
create a render_to_texture_rectangle with your screen-size (or you can even scale it down possibly , for “softened” shadows…)
then. in the pixelshader (or wherever you want, but remember register combiners are for free so use theyr mux) determine if we have the face front or backfacing. if its frontfacing, set rgb to 1, alpha to 0
if its backfacing, set rgb to 0, alpha to 1
then simply blend_add the result and draw the whole geometry…
bind this rectangle as texture and calc rgb-alpha… if its 0 (mux again), its not shadowed, else it is…
any sugggestions how to get this faster? i just want to increment 2 different values, in and out at the same time… possibly a luminance-alpha texture only possible, who knows… possibly thats faster, possibly thats even slower than rgba… possibly only rgb and incr red or blue only… what ever
Originally posted by davepermen:
[b]hey humus. i just read your code and have to say its awesome! really nice done texture-classes, and mostly i like the imaging-stuff you have, really great done. the last thing you should do in your image-process-functions is the wellknown FourierTransform… for big filters that would be very nice to process the image…
Thanks
Maybe I’ll add fourier transform to the imaging stuff sometime, but I’m not sure I’d have much use of it for the stuff I do, but then again, many of the filters I’ve implemented have never been used for something real either. I just put them in there to test my knowledge when I took an image processing course.
how is the z-correct bumpmapping realised? i know 3 ways:
a) slicing
b) generating mesh
c) using some fancy texture shader features
a) simple, yet done several times and the only point why it could be “invented” now is because of the fillrate-eater… so its as new as fur is and grass…
b) possibly some extension to NV_evaluators or something?
c) hm… i read the specs… and i don’t see anything that new in depth-stuff mather… only the GL_DOT_PRODUCT_DEPTH_REPLACE_NV wich calculates a dp3 with texcoords and previous textures color… how can this do it i dunno… and this is ps1.3 i guess, so every ati should do this, too…
)
i guess those dp3_depth stuff is for the “z correct bump mapping”…