• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

119 Neutral

About RenHoek

  • Rank
  1. Hi guys   So I have a uniform buffer which I use for material constants. This does not change very often, but it does change from time to time.  Which means I need to update the buffer contents sometimes during the course of a render. The following shows a snippit from my refreshUniforms() function. When exectuted first, it creates the uniform buffer.  And for all other executions, it simply updates the uniform buffer  ( with care to avoid Implicit synchronization )   There are two ways I have this implemented ATM.   1)  orphaning   if ( m_uniformBuffer == 0 ) {   // init the buffer   glGenBuffers( 1, &m_uniformBuffer );                                            //  create new buffer   glNamedBufferDataEXT(m_uniformBuffer, bufferSize, buf.get(), GL_STATIC_DRAW);   //  upload new data } else {   // refresh the buffer   glNamedBufferDataEXT(m_uniformBuffer, bufferSize, NULL, GL_STATIC_DRAW);        //  orphan prev data   glNamedBufferDataEXT(m_uniformBuffer, bufferSize, buf.get(), GL_STATIC_DRAW);   //  upload new data }   2)  Via Map/UnMap   if ( m_uniformBuffer == 0 ) {   // init the buffer   glGenBuffers( 1, &m_uniformBuffer );                                        //  create buffer   glNamedBufferDataEXT(m_uniformBuffer, bufferSize, NULL, GL_DYNAMIC_DRAW);   //  initialise } else {   //  orphan prev data   glNamedBufferDataEXT(m_uniformBuffer, bufferSize, NULL, GL_DYNAMIC_DRAW);    // is this line needed? }   //  upload new data GLvoid* data = glMapNamedBufferEXT( m_uniformBuffer, GL_WRITE_ONLY ); memcpy( (void*)data, (const void*)buf.get(), bufferSize ); bool mapResult = glUnmapNamedBufferEXT( m_uniformBuffer );     Question   I was previously performing option 1.  But need to move to option 2 due to a driver issue.  dont ask... : ( So my question... It is necessary to perform orphaning for option 2? If so, why?  Shouldn't the driver manage the uploading of the memory for me?  At the right time?   Cheers! Ren
  2.   Wow.   Ok.   Yes, this is was I was after.  :) Acknowledgement that there actually _are_ different levels of derivative "quality" on modern hardware.   I help author a high-end tool which runs on the most modern of cards.  We're very quality concious ( rather than speed ). So I'm going to set this hint to HighQuality regardless in our app from now on.   Question: I know derivatives are used to select mip-map levels during texturing. Do you know what happens if a polygon occupies only 1 pixel on screen?   ( or even 2x1 ) Any idea what the derivatives will give in that scenario?  And what mip-map level will be chosen?   Thanks! Ren
  3. GL_FRAGMENT_SHADER_DERIVATIVE_HINT This hint apparently enables high quality ( or low quality ) derivatives in fragement shaders.   Does anyone know if this actually does _anything_ on modern hardware? ( eg Nvidia cards etc... )   Anybody know anything about this hint? I see very little discussion about it anywhere on the internet.  :(   Thanks! Ren  
  4. Hi all I'm coding for modern CPU's. But the meshes I'm sending to the graphics card are pretty much directly output from Maya. I guess they will have poor vertex-cache-ordering. I'm hoping to use a vertex-cache-optimization pre-pass on the meshes to gain some performance. As suggested here http://home.comcast.net/~tom_forsyth/papers/fast_vert_cache_opt.html Does anyone know of the best technique to use on modern cards? Is it still Toms algorithm? The models I have to render have 1,000,000+ triangles. :( So I would like the pre-pass to run fast, as well as produce good results. ( like Toms algorithm ) 2nd Question. Does anyone know of a solid and good implementation of Toms algorithm? The ones I'm finding on the internet seem to be from junior/hobby programmers who are not writing the most efficient code. Thanks all Ren
  5. Hi there Your idea of translating everything to the 0,0,0 point seems fine Its the method I've used before. ( and other packages I've worked on ) We stored our planet geometry in the CPU in worldspace doubles. ( it was an old project ) Then converted all the double-precision data to a 32bit camera=0,0,0 positioning scheme before sending to the card. But if you're doing it using the compute shader then yea... I guess convert your matricies in a way that your data is still positioned relative to the camera rather than in world space. Humas wrote an article in GPUPro 1 which describes how to handle matricies to minimize low-precision jittering. Good luck, and I look forward to screenshots! Ren
  6. Hi all I'm currently doing a lot of work with GPU procedural noise in GLSL. Here are a few questions + notes regarding this. [b]1) [/b][b]Noise Derivatives[/b] One area I'm working on right now is calculating analytical derivatives for various noises. Inigo Quilez posted some notes on how to calculate the derivatives of value noise. ( although he incorrectly calls it perlin noise ) => http://www.iquilezles.org/www/articles/morenoise/morenoise.htm ( This noise derivative is extremely easy and fast to implement in GLSL. More so that what Inigo has posted in his CPU version. Let me know if you want it and I can post ) Inigos approach does not work for Perlin noise. Some people have incorrectly implemented it thinking that it does. => https://github.com/cinder/Cinder/blob/master/src/cinder/Perlin.cpp [ NOTE: INCORRECT! ] I have only seen one correct implementation of perlin noise with derivatives. Although it is only in 2D. => http://www.decarpentier.nl/scape-procedural-extensions Perlins Simplex noise allows for a easy derivative calculation, as kindly demonstrated by Stefan Gustavson here... => http://webstaff.itn.liu.se/~stegu/aqsis/flownoisedemo/ [b]So my question / request is if anyone has implemented Classic Perlin Noise with Analytical derivatives in 3D? Or do they know of any implementations? Thanks![/b] [b]2) Normalizing Classic Perlin noise to -1.0->1.0[/b] I've noticed a few threads on the internet of guys trying to figure out how to normalize perlin noise to a -1.0->1.0 range. eg => http://www.gamedev.net/topic/285533-2d-perlin-noise-gradient-noise-range--/ This particular thread goes on for a _very_ long time. It boggles my brain how much time they put into this thred. Sorry if they finally got the answer, or that I maybe missed the point of the thread, but I didn't have time to read it all. For me it was a very easy thing to solve so I'll post my answer here for anyone who is interested. The way to do it is to imagine the maximum possible value which could be generated by the perlin noise algorithm. In 2D this would be having all 4 ( normalized ) gradient vectors pointing to the very center of the square, and the sample being taken from the center of that square. This generates a value of sqrt( 0.5 ) = 0.70710678..... So the normalization value to scale the noise to a -1.0->1.0 range is 1.0/sqrt(0.5) In 3D it is 1.0/sqrt(0.75) Easy! Ok. Thanks all Ren Hoek
  7. Hi guys So I'm working on some stuff atm which requires random numbers within a pixel shader. I'm aiming for DX9 hardware so integer hashing is not an option. I've opted for a floating point hash from the x,y integer pixel coordinate of the form hash = mod( x*x*y*y, SOMEPRIME ) / SOMEPRIME I seem to be getting good results from it. ( I can clamp and offset the domain to avoid the reflection along the x=y diagonal line ) Thing is, the x*x*y*y operation pushes the floating point integer coordinate way past ( 2 << 23 ). So the floating point number starts to loose precision. eg, x = 99.0 y = 99.0 99.0^4 > 2.0^23 So my questions. Do modern graphics cards conform to the IEEE 32bit floating point standard? Are there any that do not? ( I think I remember some ATI cards being 24 bit at some point... ) Can I expect this function to produce the same results across different cards? At least the ones which are IEEE 32bit FP compliant right? thoughts? Thanks all! Ren
  8. [quote name='0xffffffff' timestamp='1296076048' post='4765273'] [quote name='JorenJoestar' timestamp='1296044936' post='4765004'] Can you describe better the process you are using? Are you using both normal and depth??? [/quote] Using only the color information. At each pixel the edge direction and contrast is estimated using color differences between neighboring pixels (in our version, the color of the "central" pixel is ignored for this purpose). E.g., if it's bright on the right side and dark on the left side, then the edge has a strong vertical component (put another way, the edge normal points to the left). In practice our sample placement represents a slightly rotated pair of basis vectors relative to the rows and columns of the image. The color differences are reduced to scalars (somehow) which become the weights for a sum of these basis vectors, and that sum is the "step size" for the directional blur. [attachment=1191:aa filter.jpg] [/quote] Hi there 0xffffffff I'm very interested in your approach. Do you have any example code for your technique? Thanks! Ren
  9. Progressive Mesh Source Code

    Here is the stuff from geometric tools. => http://www.geometrictools.com/LibGraphics/Detail/Detail.html The CLOD stuff. I used it in a product somewhere around 2004. I can't remember the exact details of the code, but do remember that it lifted out of his engine framework rather easily. It didn't produce the best results on some things. (eg terrains) But it worked with minimal hassle, so was good for me at the time. One gotcha is that if there are any verts in the vertex arrays that are unreferenced in the index buffer, it'll crash. So be sure to do a "cleanup" pass over your mesh data first before giving it to the clod stuff. Ren
  10. Progressive Mesh Source Code

    David Eberlys Wild Magic toolkit has a nice implementation. http://www.geometrictools.com/
  11. OpenGL Vertex Cache Optimal Grid

    Awesome. Thats exactly what I was after Thanks HellRaizer!
  12. OpenGL Vertex Cache Optimal Grid

    Thanks for the replies guys. Quote:Original post by Ingenu Tom Forsyth's version is the best. I think the first link have something even faster for a regular grid though, but using Forsyth is more generic. The thing about Toms solution is that it does not work very well for grids. He says it himself. I think I'm going to try email Tom or Ignacio Castaño directly. Watch this space. Thanks! Brian
  13. Hi Everybody I'm am currently working on some terrain rendering code. Suffice to say it has a very heavy vertex shader. So I'm keen to generate a grid primitive that has a very posttransform-cache-friendly layout. Apparently Ignacio Castaño has written a nice article on the subject. => http://castano.ludicon.com/blog/2009/02/02/optimal-grid-rendering/ But the link is down!!! :( Here are some posts that mention the link => http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=257252 => http://home.comcast.net/~tom_forsyth/blog.wiki.html#[[Regular%20mesh%20vertex%20cache%20ordering]] Now I know Tom Forsyth has written a tool to do auto vertex-optimization. And there exist other algorithms out there. But I need to generate these meshes dynamically at runtime, so the generation needs to be quick. I'd rather somehow get the knowledge that Ignacio has written about and work on from there. So does anyone know about this stuff? Does anyone know what Ignacio Castaño wrote about in his blog entry? Thanks heaps! Ren
  14. Hi Vik Again, thanks for reply. I have looked into this post. ( nice water btw :) ) => http://www.gamedev.net/community/forums/topic.asp?topic_id=527145 But I'm sorry. I still don't understand. I have read your issues, and Yann L's reply, and it does not seem to state that RGBSPD->XYZ->RGB is necessary. From what I gather you're asking if all wavelength calculations can be pre-calculated so that they can be used in the final RGB color space efficently. YannL follows up by saying "...An RGB value is a type of SPD (spectral power distribution) also,... It uses three rather wide wavelength ranges..." "...Now, consider an algorithm using, say, 20 narrow wavelength bands in its distribution:...converting them to RGB will have an impact on the result, since the lambda-dependent calculations will now operate on fewer and wider bands." Is this not simply saying that doing the calculation of 3 wavelengths will give less accurate result than on 20? [Edited by - RenHoek on March 30, 2009 9:32:22 AM]
  15. Hi Vik Thanks very much for the reply. > You need to do SPD->XYZ->RGB conversion. Do you know why this is? I understand an integration/conversion is needed if the SPD covers different wavelengths to RGB. (eg, 30 wavelengths) If my SPD contains the 3 wavelengths of RGB. This should be the same 3 wavelenghts emitted by the final pixel on screen right? So why not feed the 3 wavelength levels directly to the hardware? The reason I'm confused over the matter is that every atmospheric renderer that I have encounted on the internet does this. They feed the 3 wavelength dependent values directly into the framebuffer with no SPD->XYZ->RGB conversion. eg Eric Brunetons work => http://www-evasion.imag.fr/Membres/Eric.Bruneton/ Sean O'Neil => http://downloads.gamedev.net/features/hardcore/atmscattering/demo.zip I'm wondering now if its the difference between "What is technically correct" and "What looks good enough"?
  • Advertisement