Jump to content

  • Log In with Google      Sign In   
  • Create Account

Jason Z

Member Since 04 Feb 2004
Offline Last Active Today, 10:18 AM

Posts I've Made

In Topic: Physically Based Rendering In Directx

Today, 09:30 AM

I think you might have a hard time finding someone who can explain how to implement irradiance calculations (or approximations thereof) to a 3 year old.  If you are serious about implementing your own renderer, then you need to understand how it works.  Have you read any books on the topic?  Are you willing to put in the effort to implement and debug the system?


If not, then why not just use something like UE4 or Unity?  If so, then start digging in to the resources available - there is lots of info on YouTube with explanations, so try to go as far as you can on your own before asking someone to explain the whole thing to you.  If you get stuck on a specific piece, then there are lots of people here to help!

In Topic: you all say oculus rift but why not google glass?

14 July 2016 - 08:41 PM

Google has been investing in Magic Leap, so I guess they will eventually be using their AR technology sooner or later.  With that said, there is lots of room for many different types of interaction models - not just headsets.  You can use a smartphone for AR relatively easily, just like Pokeman...

In Topic: How to get patch id in domain shader.

28 June 2016 - 05:38 PM

That's right, but each vertex would only contain a single index into your structured buffer.  So even if you had to repeat a vertex, it would be relatively low cost.  If you have a way to generate the desired indices when given a sequential value, you could always use an empty vertex type and just generate the vertices on the fly in the vertex shader.  That would be super low cost, and you can easily expand the vertex data as needed throughout the pipeline (i.e. in the VS, DS, and HS).

In Topic: How to get patch id in domain shader.

26 June 2016 - 07:40 AM

Thank you @MJP. That make sense. And actually documentation says that though I had to read it several times to understand.


@Matias is it still true if I have a pass-through vertex shader?


And maybe you can help me with my scenario. I have a big buffer with all control points. A have several index buffers for patches. Some patches should be drawn multiple times with different transformation. So if I want to draw everything in one call I have to duplicate indices. Right now I'm drawing each patch in it's own draw call and for patches that need to be drawn multiple times I'm using instancing. Here's a problem - for each new instance SV_PrimitiveID resets to 0. SV_InstanceID is not available in hull/domain shader and I have to pass it from vertex shader unnecessary duplicating data. Looks like instancing not works very well with tessellation.


Have you considered putting your control point data into a resource that can be read by a shader (i.e. constant buffer or a structured buffer)?  That would allow you to have a very small vertex format (like a single integer offset) and you can just update your vertex buffer to indicate which set of control points you want each instance to use, and then utilize one of the basic draw calls instead of real instancing.  That should keep your primitive ID sequential, while still offering the reuse of most of your data without bloating.


Also, maybe I missed it, but what are you using the primitive ID for?  Is a unique value within the domain/hull shader needed?

In Topic: Picking In DirectX11 Using Bounding Box

26 June 2016 - 07:27 AM

To the OP: Do you understand what the code is supposed to be doing?  If you are trying to create a ray and intersect it with a bounding box, are you sure that both the ray and the box are in the same coordinate space (i.e. view space, world space, projection space, clip space, etc...)?


Try to map out what you are actually trying to accomplish, and break the overall task into smaller pieces that you can verify step by step.  If you try to do the whole task at once, then it is very difficult to debug.  On the other hand, with smaller tasks, you can more easily verify that each of them is doing what you expect.  I find that this often forces me to understand the algorithm I am implementing far better as well.