I have a renderer in DirectX 11 that uses deferred shading and tiled light culling on the compute shader. I can run 1024-2048 point lights with a steady framerate of 30-35 FPS. I however do not have global illumination.Are irradiance volumes (used in Crysis3) a better solution? Can you have 2000 irradiance volumes on scene and have 30 FPS? Or should I stick to my current method and forget about global illumination?
Related
The Rubik's Cube I've modeled using STL parts is lighted from all 6 directions with directional lights. As can be seen, the recessed areas are more lighted than the surfaces. When I load and position the STL files into Blender, rendering is fine. So I think the files are OK.
So, how can I fix lighting? Note that setting castShadows/receiveShadows on light and materials (phong/lambert/standard) doesn't seem to change anything.
Code is at https://github.com/ittayd/rubiks_trainer/blob/master/js/three-cube.mjs#L134
I think what you're seeing makes sense. When a face is pointing straight down the axis they're only affected by the light in front of them. But when a face is halfway between axes, it's affected by more than one light, creating an additive effect. You could minimize this by adding shadows, but creating a new shadowmap for 3 lights is expensive.
The Rubik's cube has 26 pieces * 3 lights = 78 drawcalls
+26 pieces for the final render = 104 drawcalls per frame!
I recommend you just bake an ambient occlusion map with Blender, then use that in your material with .aoMap to simulate those darker crevasses very cheaply, and keep your performance smooth. Once you have your AO map, you can just use a single ambientLight to illuminate everything, without needing 5 different lights (More lights = more expensive renders).
I'm using WebGL to do something very similar to image processing. I draw a single Quad in orthoscopic projection, and perform some processing in the fragment shaders. There are two steps, in the first one the original texture from the Quad is processed in the fragment shader and written to a framebuffer, a second step processes that data to the final canvas.
The users can zoom and translate the image. For this to work smoothly, I need to hit 60 fps, or this gets noticeably sluggish. This is no issue on desktop GPUs, but on mobile devices with much weaker hardware and higher resolutions this gets problematic.
The translation case is the most noticeable and problematic, the user drags the mouse pointer or their finger over the screen and the image is lagging behind. But translation is also a case where I could theoretically reuse a lot of data from the previous frame.
Ideally I'd copy the canvas from the last frame, translate it by x,y pixels, and then only do the whole image processing in fragment shaders on the parts of the canvas that aren't covered by the translated previous canvas.
Is there a way to do this in WebGL?
If you want to access the previous frame you need to draw to a texture attached to a framebuffer. Then draw that texture into the canvas translated.
I'm making a game in Unity 5, it's minecraft-like. For the world rendering I don't know if I should destroy cubes that I don't see or make them invisible.
My idea was to destroy them, but creating them each time they become visible would take too much processor power so I'm searching alternatives, is making them invisible a viable solution?
I'll be loading a ton of cubes at the same time, for those unfamiliar with minecraft, here is a screenshot so that you get the idea.
That is just a part of what is rendered at the same time in a tipical session.
Unity, like all graphics engines, can cause the GPU to process geometry that would not be visible on screen. The processes that try to limit this are culling and depth testing:
Frustum culling - prevents objects fully outside of the cameras viewing area (frustum) to be rendered. The viewing frustum is defined by the near and far clipping planes and the four planes connecting near and far on each side. This is always on in Unity and is defined by your cameras settings. Excluded objects will not be sent to the GPU.
Occlusion culling - prevents objects that are within the cameras view frustum but completely occluded by other objects from being rendered. This is not on by default. For information on how to enable and configure see occlusion culling in the Unity manual. Occluded objects will not be sent to the GPU.
Back face culling - prevents polygons with normals facing away from the camera from being rendered. This occurs at the shader level so the geometry IS processed by the GPU. Most shaders do cull back faces. See the Cull setting in the Unity shader docs.
Z-culling/depth testing - prevents polygons that won't be seen, due to being further away from the camera than opaque geometry that has already been rendered this frame, from being rendered. Only fully opaque (no transparency) polygons can cause this. Depth testing is also done in the shader and therefore geometry IS processed by the GPU. This process can be controlled by the ZWrite and ZTest settings described in the Unity shader docs.
On a related note, if you are using so many geometrically identical blocks make sure you are using a prefab. This allows Unity to reuse the same set of triangles rather than having 2 x 6 x thousands in your scene, thereby reducing GPU memory load.
A middle ground in between rendering the object as invisible or destroying it is to keep the C++ object but detach it from the scene graph.
This will give you all the rendering speed benefits of destroying it, but when it comes time to put it back you won't need to pay for recreation, just reattach it at the right place in the graph.
I'm trying to tween a Sprite's alpha to 1 using Greensock's TweenMax. cacheAsBitmap has been set to true. The Sprite fades alright at 800x600 (although you can already tell it's starting to lag), but when I set the dimensions of the Sprite to 1440x1080, the tween is significantly choppier.
The framerate drops from a consistent 24 to 11.1 when I try to tween, and CPU usage jumps from ~6% to 164%.
DisplayList Rendering before, during, and after the tween:
Top Activities:
Any tips on how I can get a smoother result?
My program is a rain particle system based on the compute shader for advancing rain drops and another rendering shader(vertex shader, geometry shader, pixel shader) for rendering the advanced rain drops.
I use the draw call: DrawInstancedIndirect to apply the results from the Compute Shader to the rendering step.
My problem is in the rendering step, at the Geometry shader, where I'm trying to draw a billboard for each rain drop. If I just draw a normal regtangle, it render well, and when I change to a billboard, nothing is in the render target. I'm trying to find a way to debug this geometry shader. I used the following tools for debugging geometry shader, but thet do work out for me.
Graphics Debugger in VS2012. It seems that this tool do not support draw call: DrawInstancedIndirect.
GPU PeftStudio. It support vertex, pixel shader, but not Geometry shader. I tried to pass out the immediate values from geometry shader to pixel shaders for seeing them, and they are all zero. But I need to dig into geometry shader for finding out the error.
Nsight by NVDIA. My graphics card is 720M, and it's so sad that Nsight only supports from 730M. May be it is the reason the shader list is empty why I am in the debugging process.
I'm desperated now, and seeing no way to find out the problem. I hope you could suggest me a way to debug this geometry shader. Thanks so much!
You can try to use RenderDoc by Crytek, it's really easy to use and you can monitor every buffers in every stages.