17
The terms have to do with the "thickness" of the voxelization. I'll illustrate with the help of a diagram about 2D line rasterization (from this unrelated question).
On the right is the typical line rasterization: the algorithm finds the one pixel nearest the line within each row (or column, depending on slope). This produces what we usually think of as a "...
9
What is missing?
Now that we can see images from your app, the difference that stands out most to me is the lack of shadows and ambient occlusion. This gives a very flat look as the colour of a surface does not vary according to its surroundings. This makes a big difference to how much an image appears to have depth.
Another effect which may be less ...
5
In the binary version you're doing an imageLoad and an imageStore on the same texture to modify it. This is a classic race condition: the GPU executes multiple threads of the shader in parallel, and there's no guarantee for those load-modify-store sequences to happen atomically. The operations from different threads can be interleaved, resulting in wrong ...
5
I'm not sure what exactly you mean by
how to visualize a plane that use w value as one of this coordinates
but here's a sketch that will, hopefully, clarify this sentence:
a line through each edge of the input triangle as a plane in homogeneous (x c , y c , w c )-space
I've used uppercase letters for clip-space, and lowercase letters for window ...
3
As you said, the RTX Turing architecture comes with wired primitive-ray intersection, (to be more specific, triangle-ray intersection). The BVH is built by specifying the Bounding Box program to OptiX, the signature of which is:
RT_PROGRAM void my_boundingbox_build_program( int, float result[6] )
As you can guess, the result must contain the minimun (3 ...
3
Illumination components
If our scenes only contain point lights (e.g., omni lights, spotlights, etc.) and emissive surfaces, the illumination contributions at a surface position, $x$, are computed as follows:
The self emission associated with the emissive surface (i.e. 0 bounces/surface interactions) is computed as usual without using the scene's ...
2
You could do this. Basically what you would do is generate a cube for each voxel (or actually nearby voxels could share the edges). Not exactly sure what benefit you would get form this, unless your intersection algorithm is somehow extremely finely tuned. It could be useful for real time rendering or some sort of sparse structure. While your at it why not ...
1
A fragment shader executes for a 2D rasterized position. When you output the normalized position it's still being projected onto the 2D xy image plane onto a render target. The render target is 2D, so you can't use the fragment shader output to achieve this.
You need to bind a 3D texture as a read/write texture in order to store values.
The other thing is ...
1
If you have this data in a 3d array where a block is a 1 and no block is a 0 you can apply a 3d blur and then set all voxels that are left with a value higher than 0.5 to 1 and those that arent to 0. this will smooth out sharp details and leave flats mostly uneffected
1
SceneKit, as of iOS 9/OS X El Capitan, can handle all of the suggested lighting changes from @trichoplax. The newly announced (June 2016) Physically Based Rendering (PBR), and support for Pixar's Universal Scene Description, make some stunningly beautiful images, if you can required iOS 10 (hint: you should).
SceneKit is using Metal or OpenGL (your choice) ...
1
1) Drawing a bunch of 3d cubes with simple textures? Yes, SceneKit can do that.
2) Way too broad a question... try reading the docs.
3) Since this is a platform specific question try the scenekit and scene-kit tags on stackOverflow and Game Development, but see answer 2 first.
good luck!
Only top voted, non community-wiki answers of a minimum length are eligible
