New answers tagged

1

I can't give you a "better" approach here, but I think that the approach to project each individual brush image onto the surface of the object is not really a performance issue if you implement that using the GPU. Especially in an editor environment, where not much is going on in comparison to a computer game. All you basically want to do is to ...


1

As long as no pixel on the texture is used twice, you can render the geometry and display the uv-coordinates (texture coordinates). Usually they are a combination of red and green (2d). When using a brush, you only need to read out the uv-coordinates you've hit and color the texture at position (uv) in the desired color. Hint: paint onto a second texture, so ...


0

You could do it in different ways. But the most logical way for me is that there are points sampled along the path, then splines/benzier curves are used to make it smooth (additonal points can be interpolated), thereafter it is projected and saved on the texture. So no "every" point has to be sampled.


1

Problem was that perspective matrix had very short Z_NEAR and Z_FAR values (0.01f and 200.0f). By changing it to much higher range (10.0f, 20000.0f), problem with jaggies and artifacts disappears.


0

Thank you Nathan! I was basing my Texture2DArray solution on MS's sample repo that you've sent, but after your explanation it was much easier to convert code to Texture2D[]. For anyone wondering, here's code: void RaytracingResources::CreateDxrPipelineAssets(ID3D12Device5* device, ModelClass* model, std::vector<TextureWithDesc> texturesWithDesc, ...


1

I think what you want for this is to create a descriptor table which lists your textures. The individual textures would be created and uploaded as ordinary Texture2Ds. You'd set up the root signature of your shader to bind your Texture2D[] in HLSL to a contiguous range of SRV descriptors from a descriptor heap. Then, when you create the SRVs for your ...


Top 50 recent answers are included