New answers tagged texture
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
