Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


B_old

Member Since 06 Sep 2002
Offline Last Active Jan 07 2015 07:48 AM

Posts I've Made

In Topic: "Random Digit Scrambling" for quasi montecarlo sampling

24 October 2014 - 04:06 AM

It looks like you are trying to understand someone else's code without understanding, or even reading, the paper: it is clearly stated in section 7 that

 

Randomized digit scrambling (section 3.2.3) is realized by just calling the routines with a random integer instead of the default parameter uint r = 0.

Hammersley sequences or the like are a higher level construct than radical inverse functions (in fact the "end product" of the whole algorithm), not a low-level primitive.

 

I read the paper and don't understand how they combine the routines to get their RDS. 

The scrambled part still makes sense to me.

func ScrambledHammersley(i, numSamples, r uint32) Vector2 {
	return MakeVector2(float32(i) / float32(numSamples), ScrambledRadicalInverse_vdC(i, r))
}

But apparently they are combining all of the three radical inverse functions to get some result.


In Topic: Decouple simulation and rendering: Interpolate particles

04 June 2014 - 01:28 AM

I see. Thanks for the input!


In Topic: OpenGL 4.4 render to SNORM

31 May 2014 - 04:53 AM

Yes, it returned GL_FRAMEBUFFER_COMPLETE.

 

Maybe the easiest thing is to render to UNORM and map [-1, 1] to [0, 1] in the shader. Not really a big deal, but I wanted to find out what the problem is.


In Topic: OpenGL 4.4 render to SNORM

30 May 2014 - 05:41 AM

Yes, I'm checking for completeness. The behavior I get is completely identical to just using a UNORM target, so it seems to be silently converting to that. I also don't get any debug output from OpenGL.

 

This is with a GeForce GTX 570, driver 331.38 on Ubuntu.

 

Do you have experience with rendering to this format?


In Topic: OpenGL 4.4 render to SNORM

29 May 2014 - 10:15 AM

I don't know. It says:

 

We are silent about requiring R, RG, RBA and RGBA rendering. This is an implementation choice.

 

As the hardware seems to perfectly capable of rendering to SNORM I expect that it is implemented for all drivers.

Has someone here successfully rendered to SNORM with OpenGL?

 

EDIT:

 

This OpenGL 4.4 core spec document also does not mark the SNORM formats as something that must be supported for a color target. Maybe it is really not supported to render to SNORM. Can anybody confirm this?


PARTNERS