Normal argument to texturing #19
Comments
|
Woah!!!!!!!!
That is exciting!!!!
…On Sat, May 19, 2018 at 5:10 AM, TLC123 ***@***.***> wrote:
When creating textures (x,y,z,t) is available to plug in to some function.
In Shadertoy there are many examples where, in addition to the (x,y,z,t)
coordinate, the normal of the field at that (x,y,z,t) point is made
available. This is of course very useful for texture generation
I hacked up a thing like this
[image: alt text]
<https://github.com/TLC123/Curv_stuff/blob/master/rgbn.png?raw=true>
the code
let
RGB_normal shape =
make_shape {
dist p : shape.dist(p),
colour p : let n= (
( normalize(
(shape.dist(p) - shape.dist(p+(0.001,0,0,0)) ) ,
(shape.dist(p) - shape.dist(p+(0,0.001,0,0)) ) ,
(shape.dist(p) - shape.dist(p+(0,0,0.001,0)) ) )));
in
max(0,n[X])*[0,1,1]+max(0,n[Y])*[0,1,0]+max(0,n[Z])*[1,1,0]+
-min(0,n[X])*[1,0,0]+-min(0,n[Y])*[1,0,1]+-min(0,n[Z])*[0,0,1]
,
bbox : shape.bbox,
is_2d : shape.is_2d,
is_3d : shape.is_3d,
};
in
union(
smooth 0.2 .union(
union(
ellipsoid (1,1.4,2) >>move(1,1,1) ,
cone {d:1, h:2}>>move(-1,1,0.5),
cylinder {d:1, h:1.5}>>move(1,-1,1),
cube 1>>move(-1,-1,1)
),
morph 0.75 ( sphere 2 , cube 1.45>>offset 0.05),
),
torus {major:4, minor:1}>>move(0,0,-1)
)
>> RGB_normal
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#19>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AQWpJX7p9JrgSSMzs4PifdYzZr9ZGL4cks5tz-GFgaJpZM4UFo9J>
.
--
Do you want to make something?
Here are the tools.
Go
*Diyode is the single most awesome toy under the tree at Christmas that I
had to grow up to get*
|
|
That's a cool demo! Have you heard the good news about automatic differentiation? Since Curv has full control over the evaluation and rendering pipeline, I'm curious if there are plans to get the normals at a language level, without needing to manually evaluate partial differences. |
|
@mkeeter: Thanks for the link, Matt. I did not know about automatic differentiation. Based on the article, I'd consider implementing forward accumulation, and also allow the user to directly specify the gradient of the distance function within a shape. |
|
(I did have plans to provide normals at the language level, but that was years ago, and higher priority work kept getting in the way. Automatic differentiation looks easier than the symbolic differentiation that I had previously considered.) |
|
Hi @TLC123, I decided to speed up your code. First, in RGB_normal, in make_shape, in colour, I cached the value of Next, I fixed a performance bug in the Curv GLSL compiler, and that got me from 15 to 30 FPS. See: 878cf2b Finally, the Here's my revision of your code: |
|
Thanks. Assuming Automatic differentiation is cheap shouldn't that gradient slope help determine a truer step-size in sphere tracing of unruly distance fields? There might be more benefits than mere textures. |
|
I compute multiple gradients per pixel in the lighting model, so this could speed up rendering. Sphere tracing works on distance fields that aren't differentiable. For something like a cube, the distance field isn't differentiable at edges and corners. For something like the Mandelbulb, the DF is not differentiable anywhere. However, Sphere tracing requires the distance field to be Lipschitz(1) continuous. There are some distance fields that are not Lipschitz continuous, but which are C1-continuous (differentiable everywhere, and the derivative is continuous). For these distance fields, I could use a root finding technique that uses the derivative for ray-casting. The problem is the limited applicability. What if I union a C1-continuous DF with another shape? The output of union is not C1-continuous, so how do I render it? What I would like is a ray-casting method that works on any continuous distance field, even if it is not Lipschitz-continuous. This method does not require differentiability, so it works on Mandelbulb. It's expected to be slower than sphere tracing. Then I can use this alternate method instead of sphere tracing if the DF is not Lipschitz. |
|
I think this started as a feature request for a high level interface for making textures that have access to the normal. Okay, here's my initial idea for this. |
|
I was trying to get rid of the sharp colour banding. I realized that the output of |
|
Brilliant. Works like a charm. Just one question. I tried and failed. What if i need to pass say two arguments a and b or maybe a list to my f function. Some times i do, sometimes i don't |
|
@TLC123 The reason that A more detailed answer is: if you call a function, passing fewer arguments than are required, then this is legal, and what you get back is another function that consumes the remaining arguments. This is called 'Currying', and Curv functions with 2 or more arguments are called 'Curried functions'. In the example, you define So More generally, if |
When creating textures (x,y,z,t) is available to plug in to some function.
In Shadertoy there are many examples where, in addition to the (x,y,z,t) coordinate, the normal of the field at that (x,y,z,t) point is made available. This is of course very useful for texture generation
I hacked up a thing like this
https://www.shadertoy.com/view/ld3BDj
the code
let
The text was updated successfully, but these errors were encountered: