Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 06 Sep 2002
Offline Last Active Apr 21 2016 05:18 AM

Topics I've Started

Solar radiance in Hosek sky model

21 April 2016 - 02:51 AM

I'm currently looking at the Hosek sky model and experimenting with the provided source code.

At the moment the results for arhosekskymodel_radiance() vs arhosekskymodel_solar_radiance() are confusing to me.


Using the spectral arhosekskymodel_radiance() and converting it to RGB gives me:


Attached File  hosek_expected.jpg   37.73KB   0 downloads.


Notice that I manually added in a sun, but it only affects a very small area of the image.


Using arhosekskymodel_solar_radiance() and converting to RGB gives me:


Attached File  hosek_actual.jpg   40.33KB   0 downloads


In this case the sun is directly provided by the hosek model. The positions match but the color of the sky is completely different. I was expecting the exact same result, expect for the small area where the sun is visible. The bright point of the hosek sun is at the same position as my manually rendered solar disk, but I also get vastly different results for rays that don't directly hit the sun at all.


From looking at the interface I was expecting that I can call arhosekskymodel_solar_radiance() with the exact same parameters as arhosekskymodel_radiance() and it will just work. Is this assumption correct? Does anyone have experience with this model? I don't think it is a matter spectral to RGB conversion, as I use the spectral version of the hosek functions in both cases, so the conversion is identical. 


Could it be that arhosekskymodel_solar_radiance() should only be used when rendering the solar disk? But that would mean, that you can render an arbitrarily large sun that don't match the assumptions the hosek model makes.



After reading the comments in the code I'm now pretty sure that arhosekskymodel_solar_radiance() should only be used when rendering the solar disk!

"Random Digit Scrambling" for quasi montecarlo sampling

22 October 2014 - 06:03 AM

In the paper Efficient Multidimensional Sampling the authors describe a technique they call Random Digit Scrambling (RDS). Has someone more implementation details on this algorithm? The paper gives source code for three different radical inverse functions that can be used to implement RDS but I don't understand how they should be applied.

I especially don't understand how they jump from Hammersley samples to RDS. 

func Hammersley(i, numSamples uint32) Vector2 {
	return MakeVector2(float32(i) / float32(numSamples), radicalInverse_vdC(i))

Can the above snippet easily be changed to something that generates RDS?

Decouple simulation and rendering: Interpolate particles

03 June 2014 - 09:02 AM

If simulation and rendering run at different frequencies it can be useful to interpolate between two simulation steps during rendering for smooth animations.

For moving meshes I simply interpolate the transformation on the CPU before sending to the GPU.


For particles, which I simulate entirely on the CPU, I'm less sure about a good strategy.

Currently I keep the particle array from the previous simulation frame around and send both to the GPU where I do the interpolation. I figured doing this on the GPU is faster even though I'm sending twice the data over now. Does this make sense or would you do the interpolation on the CPU as well?


I have two arrays of particle structs. One for the previous and the other for the current frame. Before each simulation frame I just copy the array. I send them to the GPU as two separate buffers. Would it be smarter to store it as one interleaved array?


Particle rendering is currently not a bottleneck for the scenes I have (at least not the number of particles), but I would like to set it up somewhat sane. How would you handle this?

OpenGL 4.4 render to SNORM

29 May 2014 - 07:27 AM



is it possible to a SNORM texture in OpenGL 4.4? Apparently they are not a required format for color targets in 4.2.


I want to render to a RG16_SNORM target to store normals in octahedron format. The linked paper contains code that expects and outputs data in the [-1, 1] range and I was just assuming that it would automatically work with SNORM textures.


The output seems to get clamped to [0, 1] though. It checked with a floating point render target and got the expected results so I don't think it is an issue with the code.


Should this work? Am I maybe doing something wrong when creating the texture?




D3D11 hardware supports SNORM render targets, so I guess I'm doing something wrong.

Registering an uninstanciable reference type: Identifier 'XXX' is not a data type

26 May 2014 - 03:32 PM

I have a C++ type that I don't want to instantiate from scripts and only use as handles, preferably by passing it to the constructor for script classes that should be able to interact with it.


I followed the documentation and used asOBJ_NOCOUNT and did not provide a factory behavior. Actually, this is all I did (never mind the wrapper):

engine.register_object_type("Scene", 0, asOBJ_REF | asOBJ_NOCOUNT);

engine.register_object_method("Scene", "const string &name() const", asMETHODPR(scene::Scene, name, () const, const std::string&));

When I try to load a script that looks like this:

class Scene_test
	Scene_test(Scene@ scene)
		scene_ = scene;

	void on_scene_loaded()
		print("Hello World");

	Scene@ scene_;

I get an error stating "Identifier 'Scene' is not a data type".


Any idea what I'm missing?