lomateron
Member
Content count
515 
Joined

Last visited
Community Reputation
491 NeutralAbout lomateron

Rank
Advanced Member

If I have 10 different shaders for drawing 10 different shaded objects that need the same view matrix do I need to update this view matrix for every shader which means that I have to call gl.uniformMatrix4fv() 10 times every frame? In directx 10 in one file I can have 10 shaders and only one global "viewMatrix" variable which means I only need to update the view matrix one time per frame. Can something similar be done in webGL?

I have an ID3D10EffectVectorVariable in HLSL code it looks like this: int4 array; float4 VS() { uint x = 0; //"x" is loaded from texture can be a value bigger than 3 int grab = array[x]; if(x > 3) { grab = 0; } //blablabla } is this code safe?

vertex shader useless when using geometry shader?
lomateron posted a topic in Graphics and GPU Programming
if I have a technique that uses the geometry shader, is there any reason to use the vertex shader to do something( except for passing input assembler data to the geometry shader )? Is it faster to do the heavy part of an algorithm in the vertex shader and use the geometry shader only to generate the extra mesh? 
request HLSL support for sqrt() for integers
lomateron replied to lomateron's topic in Graphics and GPU Programming
HLSL trigonometric functions are sin() cos() tan() etc... 
request HLSL support for sqrt() for integers
lomateron replied to lomateron's topic in Graphics and GPU Programming
HLSL trigonometric functions have some magic going on behind it, that's why I want them to do a length() for uints, they could make something that will let the function calculate all vectors that have a length less than 2^32 
request HLSL support for sqrt() for integers
lomateron replied to lomateron's topic in Graphics and GPU Programming
wait what? uint operations are more accurate than float operations, as I said you can change the definition of 0 to 1 at your own taste, so I can make (0 to 1) = (0 to 2^25) and this will make it 2 times more accurate than (0 to 1) float 
request HLSL support for sqrt() for integers
lomateron replied to lomateron's topic in Graphics and GPU Programming
float operations have a margin of error too, when using uints you just have to change your definition of what 0 to 1 means, for example 0 to 1 in my world physics engine is 0 to 2^9 uint. 
request HLSL support for sqrt() for integers
lomateron replied to lomateron's topic in Graphics and GPU Programming
just tested HLSL intrinsic length() vs my integer length2D() and length3D() my functions are deterministic, HLSL intrinsic length() isn't, tested on an old ATI vs a new NVIDIA, on HLSL 4. You should test it yourself and that should be enough reason, for the people that want determinism. 
request HLSL support for sqrt() for integers
lomateron replied to lomateron's topic in Graphics and GPU Programming
so there is that case when the length of the vector is 1 and another case when its 0 and some other cases when it is bigger than 2^32 but there are a whole lot more cases when it actually makes sense and those outweighs the other, so it actually makes sense to make that function, its the same with float operations isn't it, its even worse, there are more cases when length() doesn't work with float vectors. what do I propose whent its bigger than 2^32? return the same value when any number is divided by 0. 
request HLSL support for sqrt() for integers
lomateron replied to lomateron's topic in Graphics and GPU Programming
arrrgg I messed up in the title, pls read the whole question, I would like to request to the people that make the intrinsic HLSL functions to make a length() function for uint vectors that gets a correct answer for every vector value uint4(0 to 2^32,0 to 2^32,0 to 2^32,0 to 2^32) 
request HLSL support for sqrt() for integers
lomateron posted a topic in Graphics and GPU Programming
The problem is that float operations are not deterministic on GPU so sqrt() should support ints for those people that want determinism. I created my own sqrt() for ints, Its actually a function to get the length of a 2D uint vector but it has the limitation of only getting the correct results for numbers from 0 to 2^15. uint length2D(uint2 u, uint b) { //dot uint l = u.x*u.x + u.y*u.y; //aproximation of sqrt() b = b + ((u.x + u.y  b) >> 1); //aproximate it more using babilonian method b = (b + (l / b)) >> 1; b = (b + (l / b)) >> 1; b = (b + (l / b)) >> 1; return b; } "b" is the biggest value in the "u" vector oops its actually a request for a faster length() function for ints that can support every vector dimension(from 2D to 4D) and correct answer for every number from 0 to 2^32. 
how Nvidia does the balls collision detection in Flex without using a 3D grid?
lomateron posted a topic in Graphics and GPU Programming
at 7:15 in this video https://youtu.be/XISqvBVyASo?t=435 He says it's grid free, you can download the demo to play with the balls and in some worlds you can move the balls anywhere you want, no walls 
getting rid of near and far clipping planes
lomateron replied to lomateron's topic in Graphics and GPU Programming
My final optimized solution which has a near clipping plane and an infinite far plane: Only 2 variables of the Projection matrix are needed, the ones that modify Pos.xy so we don't need to pass the whole 16 floats of the matrix to the shaders. Lets call these 2 variables ProjecXY Now in the vertex shader instead of doing this: Pos = mul(Pos, Projection); do this: Pos.xy*= ProjecXY; Pos.w = Pos.z; Pos.z = NEAR_PLANE; //NEAR_PLANE = 0.5f and finally reverse the depth test instead of passing if smaller, pass when greater 
getting rid of near and far clipping planes
lomateron posted a topic in Graphics and GPU Programming
The near and far planes operation makes the depth resolution poop. I want every object in front and in the field of view of the camera to be rendered doesn't matter the distance, until its so small it can't be seen but still rendered. In the vertex shader after the Projection multiplication I have tried this: float4 r = mul(Pos, Projection); r.xy /= abs(Pos.z); r.z = Pos.z*MAX_DEPTH; r.w = 1.0f; if(Pos.z<0.0f) { r.w = 1.0f; } return r; MAX_DEPTH is (1.0f/16777216.0f) so that any float distance gets rendered...16777216 = 2^24 but it still doesn't works, well the mesh is rendered correctly but when the camera is near and you read the depth and positions pixels across the mesh they are off and this off thing increases as the pixels gets near the camera I want to know what is happening to SV_POSITION after it leaves the vertex shader? I know that "xyz" get divided by the abs() of "w" what other operations happen in that part were it gets divided by "w"? if someone has already a way to render the way I want can you share it too? 
render any float value to 32bit depth buffer
lomateron posted a topic in Graphics and GPU Programming
Using directx 10 I changed DepthClipEnable = FALSE; and changed the viewport to vpTRY.MinDepth = 0.0f; vpTRY.MaxDepth = 16777216.0f; but I still can't render a 10.0f float value to the 32 bit depth buffer What else do I need to configure?