Jump to content

  • Log In with Google      Sign In   
  • Create Account


MrOMGWTF

Member Since 26 Jul 2012
Offline Last Active Mar 03 2014 09:16 AM
-----

#5009106 Shadows from point lights

Posted by MrOMGWTF on 10 December 2012 - 10:02 AM

The cube version sounds very much easier. Does it still use perspective projection?


You always use ortographic projection afaik.


#5008749 Closure's logo - disappating vapor effect

Posted by MrOMGWTF on 09 December 2012 - 03:40 AM

http://glsl.heroku.com/e#5286.0

The code isn't optimized in any way, it's slow. You need to optimize it. It looks pretty similar huh?


#4996459 Ray Tracing: Texture Map a Sphere

Posted by MrOMGWTF on 02 November 2012 - 01:56 AM

Posted Image
Posted Image

dx, dy, dz - Normal of the sphere.


#4992246 Is there anyway to protect a DirectX application from being hooked?

Posted by MrOMGWTF on 20 October 2012 - 02:01 PM

http://www.codeproject.com/Articles/30815/An-Anti-Reverse-Engineering-Guide
Enjoy.


#4989987 Simple diffuse light. Weird Behavior.

Posted by MrOMGWTF on 14 October 2012 - 12:30 AM

(spherical harmonics or environment mapping are better approaches for ambient lighting though).


Here's little code snippet for SH lighting:
varying vec3 Normal;

const float C1 = 0.429043;
const float C2 = 0.511664;
const float C3 = 0.743125;
const float C4 = 0.886227;
const float C5 = 0.247708;

// Constants for Old Town Square lighting
const vec3 L00  = vec3( 0.871297,  0.875222,  0.864470);
const vec3 L1m1 = vec3( 0.175058,  0.245335,  0.312891);
const vec3 L10  = vec3( 0.034675,  0.036107,  0.037362);
const vec3 L11  = vec3(-0.004629, -0.029448, -0.048028);
const vec3 L2m2 = vec3(-0.120535, -0.121160, -0.117507);
const vec3 L2m1 = vec3( 0.003242,  0.003624,  0.007511);
const vec3 L20  = vec3(-0.028667, -0.024926, -0.020998);
const vec3 L21  = vec3(-0.077539, -0.086325, -0.091591);
const vec3 L22  = vec3(-0.161784, -0.191783, -0.219152);

void main()
{
    vec3 AmbientColor =  C1 * L22 * (Normal.x * Normal.x - Normal.y * Normal.y) +
                    C3 * L20 * Normal.z * Normal.z +
                    C4 * L00 -
                    C5 * L20 +
                    2.0 * C1 * L2m2 * Normal.x * Normal.y +
                    2.0 * C1 * L21  * Normal.x * Normal.z +
                    2.0 * C1 * L2m1 * Normal.y * Normal.z +
                    2.0 * C2 * L11  * Normal.x +
                    2.0 * C2 * L1m1 * Normal.y +   
                    2.0 * C2 * L10  * Normal.z;

    gl_FragCoord = AmbientColor;
}

It was taken from some article about sh... I can't find it.

You can use only 2 sh bands and you will still get nice ambient light. Here's code if you want to use two bands:
varying vec3 Normal;

const float C1 = 0.429043;
const float C2 = 0.511664;
const float C3 = 0.743125;
const float C4 = 0.886227;
const float C5 = 0.247708;

// Constants for Old Town Square lighting
const vec3 L00  = vec3( 0.871297,  0.875222,  0.864470);
const vec3 L1m1 = vec3( 0.175058,  0.245335,  0.312891);
const vec3 L10  = vec3( 0.034675,  0.036107,  0.037362);
const vec3 L11  = vec3(-0.004629, -0.029448, -0.048028);

void main()
{

    vec3 AmbientColor =  C4 * L00 -
                    2.0 * C2 * L11  * Normal.x +
                    2.0 * C2 * L1m1 * Normal.y +   
                    2.0 * C2 * L10  * Normal.z;

    gl_FragCoord = AmbientColor;
}



#4983197 file format for maps

Posted by MrOMGWTF on 24 September 2012 - 06:34 AM


An octree is a run-time structure that is created and maintained dynamically. It does not belong in a file, nor can it be used to “store geometric data”.
You will have to be more specific accurate about what you want, and you should probably read up on what octrees are.


L. Spiro


I think you misunderstood me. I just want to store octrees in my map file for quicker loading times. But I didn't know that octree generating in run time is quick.

Just make it yourself. Be creative
You can use xml parser for making your life easier. Example map format:

<map>
<objects>
<object type="light" position="0.0 10.0 5.0" color="1.0 1.0 1.0" />
<object type="geom" position="0.0 0.0 10.0">
<verticies ="blah blah" />
</object>
</objects>
</map>

BSP file format made me lazy Posted Image but I think I have to do it..


Well, good luck! It's not hard, I'm making my 3d model file format right now :)


#4982092 Results on Voxel Cone Tracing

Posted by MrOMGWTF on 20 September 2012 - 11:14 AM

Thanks for your replies, guys.


I downloaded the demo on your site, im pretty sure its the same one but I only get a black screen O.o


Sorry to disappoint you but the demo on my site is a bit old and doesn't include these new features. The black screen must be caused by some incompatibility with your graphics card, unfortunately the demo was only tested on an Nvidia GTX 260 so it should work well on any NVidia card above that. Also, make sure you have updated drivers.

How are you choosing your grid bounds?
- Is the voxelization done at runtime? I assume no? ("voxelization is performed on the CPU with raytracing")
- The intersection generated by the +X ray is injected into the -X 3D texture?
- During cone trace, how are you dealing with occlusion?
- "which makes them look displaced from the scene even for glossy reflections." What does this mean? Shouldn't Eye <-> Glossy <-> Diffuse <-> Light work?

Also, is there SSAO in those screenshots?


The grid is fixed at the world origin with dimensions of 30x30x30 meters.
The voxelization can be redone in runtime but it is not real-time. The raytracing takes about 1 second and inserting the points into the volumes is slow as hell taking about 8 seconds. This step is far from optimized because I'm not even using vertex buffers for rendering the points, I'm rendering them with glBegin/glEnd (shame on me, I know).
The intersection generated by the +X ray is not necessarly injected into the -X volume. The rays are cast in all 6 directions only to ensure the voxel representation of the scene has no holes. The injection into the 6 destination volumes depends only on the normal of the point which is what represents the direction of the radiance.
Occlusion is dealt by keeping track of the accumulated opacity of all the samples processed for that cone. Think of it as regular transparency blending, where each sample is a semi transparent window that partially occludes the next sample.
The reflections don't look good because the voxel representation of the scene contains only direct lighting. So, what you'll see in the reflection is the scene lit by your light sources but being completely black on the shadows.
Regarding the SSAO, yes I have it. But the cool thing about this technique is that if you use enough cones you don't even need SSAO since the technique provides that effect for free and with much more realism.


What about my question, hm?


#4981722 file format for maps

Posted by MrOMGWTF on 19 September 2012 - 09:46 AM

Just make it yourself. Be creative :)
You can use xml parser for making your life easier. Example map format:
<map>
<objects>
<object type="light" position="0.0 10.0 5.0" color="1.0 1.0 1.0" />
<object type="geom" position="0.0 0.0 10.0">
<verticies ="blah blah" />
</object>
</objects>
</map>



#4980315 Global Illumination Test Scene for you :P

Posted by MrOMGWTF on 15 September 2012 - 02:06 AM

Shameless self-bump..


#4978248 Global Illumination Test Scene for you :P

Posted by MrOMGWTF on 09 September 2012 - 04:48 AM

Hi, I've made a simple test scene for testing global illumination in it.
I'm sharing it with you. Here's how it looks (No real GI here, just a directional light + a white-red point light to simulate GI):

Posted Image

Link to download: https://www.dropbox.com/s/taol6xvij8t5msf/Indirect%20Room.rar

License:
Spoiler


Enjoy :P


#4976010 An idea for rendering geometry

Posted by MrOMGWTF on 03 September 2012 - 04:46 AM

Voxels. It's all about voxels.


#4974359 Question about generating rays from camera.

Posted by MrOMGWTF on 29 August 2012 - 02:45 AM

You are ray-marching, not ray-tracing, so your rays die after a certain distance travelled (as far as I can guess - you haven't mentioned what you do with your rays) so that would explain the arcing horizon. A perspective projection cannot by definition cause straight lines to appear curved, so the curved horizon doesn't come from the camera - as far as I can tell anyway, the camera code looks fine, although the camera position and direction are hardcoded.


The position isn't hardcoded, there is no rotation. To rotate a camera I have to multiply the ray direction vector by rotation matrix, right?

@edit And yes, I increased the max distance from 100 to 1000, and the plane is now flat. Thanks for the help.


PARTNERS