# obhi

Member

150

196 Neutral

• Rank
Member
1. ## Perspective projection: Intersection length between light and view

No problem, you provided a very helpful pictorial explanation :)
2. ## Anyone here a self-taught graphics programmer?

I am a self taught programmer.. i used to go to internet cafe's to learn about D3D (DX7-8) cause i had no internet at home. I got my first computer when I was 16 and coded up a car racing game using the Turb C++ and VGA drivers. My interest on computer games has been on and off, until I started working full time on CAD and a 3D rendering engine for a reputed french company.   Having said that, and trying my own bit to build my own graphics engine, I still find the total amount of work for a single developer extremely overwhelming. Although not impossible.
3. ## Perspective projection: Intersection length between light and view

So at 2D the lenght becomes X/2, which means a the surface pixel count should be (for rs units) rs*ds. And the blue line: d*cos(theta) = percieved length = rs*ds (from inverse sq).. Thanks a lot :)
4. ## Perspective projection: Intersection length between light and view

Hi,   I have always wondered on this, may be i am missing something very simple, in the perspective shadow map calculation from the paper: http://www.cs.berkeley.edu/~ravir/6160-fall04/papers/p557-stamminger.pdf   In section 1.1, it mentions that when a ray bundle from shadow map hits the surface at a distance rs with an angle substended at alpha, and the shadow map pixel width is ds, the lenght of the surface hit is equal to approximately: dsrs/(cos(alpha).   How do we arrive at this derivition?   Any help is much appreciated.   Thanks, obhi
5. ## Frostbite rendering architecture question.

I was planning on doing some fancy hash stuff, but for now I'm using the address of the state/command object as it's hash, and it's working great (well enough for me to not bothering revisiting yet). Yes, two different state-groups that set the same state-value will not be detected as redundant (because their pointer values will be different, despite their values being the same), however, it turns out in practice that these kinds of state-groups are often shared between different objects, meaning that the pointer values are[/font][font="arial, verdana, tahoma, sans-serif"] the same.[/font] Hashing of the sate would probably be a better choice in the long-run though... As always, YMMV For sorting opaque objects, I create a hash from the address of the most expensive state-groups -- usually the material and shader ones. e.g. something like:u32 shader = (u32)pShaderState; u32 material = (u32)pMaterialState; u32 hash = ((shader^(shader<<16))&0xFFFF0000) | ((material^(material>>16))&0xFFFF); how do one handle rendering a separate view using a simple render queue[/quote]A separate view means a different visible-set from the culling system. I'd personally create an entirely separate queue for each view. [/quote] Thank you very much for that go. I was stuck with this for so long now...on that separate view problem...about weather having visibility sets is a good option or having a robust command queue which can sort up commands (grouped) was a better choice. After a lot of pondering with different approaches that might be possible, I am sure its better to have visibility sets, with each writing to the command queue. It will be lesser sorts, can have multiple visibility sets based on camera/view etc, a simpler command queue that can be easily swapped if doing multithreaded rendering. I got bored after thinking too much into this and almost let go of the rendering part...now I think I will be going for it, just needed a confirmation. Thanks again. obhi
6. ## Sorting Objects

I am having some difficulty regarding the key sorted approach mentioned. I am trying to tie up rendering commands (set shader params, set render targets, etc) + draw calls (set pass, draw primitive) into a command queue, and sort that queue. This apparently means I do not want the commands and draw calls to go out of order, but only sort the draw calls based on certain properties. I thought this would be a convenient approach as I would not need to maintain a separate list of sorted primitives for each scene-cull, however after much considering as to how to go about creating the key for such a sparse-sort order I am thinking if having separate buckets is a better approach (less elements to sort, no complex key needed). For Eg: The queue may look like: * Set Render Target * Set View Port * Set Pass P1 * Set Shader Param T1 * Draw O1 * Set Shader Param T2 * Draw O2 * Set Pass P2 * ... The problem is to keep the grouped draw calls and set calls in order, which requires me to use a grouping number in the key, something like: [ layer | command | material id | distance | group number ] I will have to think up something better however as the key is becoming very redundant.

8. ## Rendering architecture

I was thinking more of using simple quads generated from the bounds rather than the whole object for the occ test. So for instanced and batched objects multiple quads (batched, and all calculated on the CPU) can drawn up rather than a single one per object. It will be more like a fill test. On a side note I padded the occ query and result query by the shadow map generation so that the command queue may be flushed by the end of it. Just before rendering the G-Buffer I will check on the query result. I do agree however that the queries will incur extra draw calls, which is what should be avoided first. Thanks, obhi
9. ## Rendering architecture

I am doing a pre pass mainly because of the occlusion culling. To avoid the gpu stalls may be something in the lines of what nvidia's article regarding using previous frames query result can be used?? I will use a few main shadow casting lights. Thanks for this suggestion. Thanks for your reply obhi
10. ## Rendering architecture

I have been trying to come up with a good architecture design that can after reading some good posts in gamdev have gone a little distance. My current design can be laid out as such: Scene traversal and cull lists the renderable objects in a list : VisiblitySet The renderer determines the order of rendering the visible objects based on the object type mask and fills up a command buffer : RenderCmdBuffer The deferred rendering algorithm are laid out as such: o Do Animations and Stream Out. o Disable color write and enable depth write o Depth Pre Pass (only for opaque objects) o Disable depth write o if ( occlusion query is enabled ) o Hardware Occlusion query based on the visible list and discard occluded objects o For each visible light: o Query visibility sets from light's perspective VLi upto max shadow depth buffers cap o For each visible objects render to light's depth buffer o Do a G-Buffer pass with depth write disabled for all the visible objects ( minus the discarded ones in Occ query ). o Do Illumination pass for each light. o Forward render alpha blended objects + particle systems. The whole algorithm will write to a command buffer which will be dispatched to the renderer for execution. Various per-object - per-shader based parameters will also be allocated within the command buffer and transferred to the render api. One more approach that caught up with me was to automate the sorting using the command buffer and using a key per command. This article discusses this approach. This would allow me to pass the command buffer to each visible object and add them to the command buffer as per the render technique. The only problem I am facing is a single object might register to the command buffer twice or more with different vertex format (1. For depth pre pass, 2. For G Buffer). This would incur me double sorting of the same render objects. In-order to avoid this I am considering building the visibility sets and then filling up the command buffer in preprocessing (commands will have no key in this case). Also considering the fact that this will detach the object rendering code from object to the renderer I am gussing this will be a better approach. Anyone care to add something? Thanks, obhi

Don't need to assume it is a point light at all! Spherical harmonics are great at encoding complex lighting environments (not as great as Haar wavelets apparently but I haven't looked into them). Think of it as compressing a full environment map into just a few numbers (massively lossy of course). Another way to think of an environment map is "what colour/brightness is the incoming light from each possible direction". So you can reverse this and instead encode into the environment map for a single point (vertex or texel) what colour/brightness that point is when a directional light is cast on it from all possible directions. In some cases it will be lit, some it will be shadowed by other geometry, and some it will have secondary illumination from ambient lighting and light bounces. Then you can encode this environment into a SH with a limited number of coefficients, and hard code it into vertex data or textures. Then when you want to simulate a directional light you can encode the directional light into the same number of SH coefficients and simply multiply all the environment coefficients by these, like a mask, in your shaders. The directional light can be created by taking a cardinal axis SH and rotating it (there is a fairly easy way to rotate SH) to the direction of the light. If you want you can also create much more complex lighting environments and apply them instead. Google for Precomputed radiance transfer (PRT) and spherical harmonics and it throws up a few papers. [/quote] Ah I saw the DX demo for PRT last day and the video too. Also your planet rendering videos, really great stuff. If I understand what you mean then since SH coefficients are rotation invariant, multiplying the directional light's SH components with the precomputed per-vertex or texel transfers will work out even when directional light's direction changes. I will dig some articles on this once I get my renderer ready. You really got me interested on the procedural generation however. Thanks.

No the SH in the case of dynamic directional lighting represents the lighting environment for ALL directions that the light could come from. So you simply multiply the SH encoded into the vertices or texture by a SH that represents the dynamic light (i.e. a SH coefficient set that represents a lit point in the direction of the directional light). Really, just look at the video I posted. That uses SH to encode the light from all possible directions, then allows the light direction to be changed in real time, and all it costs is 9 muls in either the vertex or pixel shader, and some more storage in either the verts or the textures. [/quote] That would be really nice. I am at work so couldnt check the video. But I can see how that will work as all we can assume the directional light as a point alight, calculate the coefficients and then only use the coefficient depending upon the direction of light. Thanks, obhi

Wouldn't this give me shadows that don't match the geometry I'm seeing? It seems like I want the geometry transformed for LOD around the camera, rendered from the perspective of the light. Furthermore with Transform Feedback I can quickly render the same terrain 3 times, one for the eye pass, one for the shadow pass, and one inverted for a surface reflection pass... [/quote] Feedback will not help because the POVs will change considering the camera view point is different from light view point. So, this is kind of no win if you use stream out (and I guess you will not be rendering the full terrain grid or at least cull away the unncessesary grids from different view point). Rendering (and culling) from the light POV and doing the shadow pass will not be performance intensive considering depth only passes are quite fast on mordern GPUs. The depth only pass will take a separate (read: optimized) pipeline to render on to the floating point texture. I think parral split shadow maps or cascaded shadow maps will yeild good results without any performance drop. Vertex transforms are anyway pretty fast. @[color="#284b72"]bluntman I havent read much on SH but I m sure they will work quite well with static point lights. However wouldn't changing the direction of the directional light would cause SH coefficients to get invalidated. In which case I think (since the directional light cannot be varied at least in motion), a baked light map will be better. However, having said all that, I know intensity can be varied so its a good tradeoff.