Jump to content

  • Log In with Google      Sign In   
  • Create Account

dpadam450

Member Since 18 Nov 2005
Online Last Active Yesterday, 11:42 PM

Posts I've Made

In Topic: Dynamic Environment Cubemap

Yesterday, 04:13 PM

Cool. The thing I was suggesting about that matrix multiply is that I have 4 varying vectors, normal/view vec in both world space and camera space. I compute those both in the vertex shader and interpolate the values. As opposed to just have noraml/viewvec in camera space and then doing a matrix multiply inversion later. The matrix multiply in the pixel shader should be more expensive than what I'm suggesting. Probably won't change your framerate but it saves some cycles.


In Topic: Dynamic Environment Cubemap

Yesterday, 03:18 PM

I've had issues before either in the rendering or the reflection vector.  I suggest using a sphere to debug.

 

In my current shader, I have to flip the x-axis of the reflection vector: texCube(envMap, vec3(refVec.x*-1, refVec.y, refVec.z) ). Pretty sure that is just an issue with my current code as I dont recall doing that before.  But I've had issues where I had to convert the vector from GL to DX coordinates because the cube map is stored in directX coordinates most likely. So try flipping y and z, and/or negating one of those after flipping.

 

aside from that, you could also be potentially rendering to the wrong cube face on accident or using the wrong view matrix to render to the face.

 

 

vec4 R_World = inverseView * vec4(R, 0.0);

 

You could also using an interpolate/varying of the world eye/camera and get rid of the matrix multiply in the pixel shader.


In Topic: Help with PBR implementation

28 June 2016 - 09:42 AM

You have to learn to debug it. The issue currently seems to be that your dot product is working just in a bad direction so see what those variables look like as color outputs.. You can output the light direction, normal etc as colors and determine what is going wrong.

 

Aside from that, strip it down to a simpler shader.  Outputing vec4(NdotL, NdotL, NdotL , 1) should clearly give you a white surface on the top. I think you may want to start from a simpler phong model and work your way up.


In Topic: Proper billboarding/impostors for asteroids fields, where object instances ar...

28 June 2016 - 08:12 AM

 

Out of curiosity, how is it done in 3D to know when you reach a time when extra details adds too many burden and steals an unacceptable amount of cycles

 

When you are writing the same pixel over and over (meaning you have an asteroid behind an asteroid behind an asteroid and if you draw in reverse order it will continually update the same pixel), or you have very tiny triangles. If you have triangles that are 1x1 pixel or so, then it will chew up performance. Pixel shaders run on 2x2 blocks of pixels for mip mapping reasons so if you have a bunch of tiny triangles it causes a ton more work at a single pixel location.

 

In the case of an asteroid field, most of the screen isn't going to be drawn, just a bunch of small/fairly small asteroids, that is why you want to LOD down to like 20 verts or so because you don't even know the difference at that far away. You can't make out much geometric shape.


In Topic: Proper billboarding/impostors for asteroids fields, where object instances ar...

28 June 2016 - 12:44 AM

If you are using instancing, that is 10 different models, so only 10 draw calls. So how many models do you have? What is the vertex count?  Why not LOD the asteroid geometry into 1 or 2 more LOD levels. If you are using displacement mapping then LOD geometry is as simple as a sphere with less subdivisions.

 

If you really wanted to get fancy, those 10 draw calls could be reduces to 1 if you are passing per object matrices and per object id's in range 1 to 10. In the shader you can use a texture array and use the id to look at a certain displacement map. (Not sure if texture arrays are supported in vertex shader but they probably do in the modern feature set).

 

Regardless, how many triangles are you pushing? I would think it would be much simpler to just LOD until performance is good (you could get it down to probably 20 verts per asteroid). You should easily be able to push a million verts which would be 50,000 asteroids above 60fps.


PARTNERS