On 4/2/25 05:13, ingo wrote:
>        turbulence: (
>          strength: (x: 1.6, y: 2.2),
>          lambda: 2.5,
>          omega: 0.7,
>          octaves: 6
>        )

Interesting. I'm impressed you implemented at 2D perlin turbulence() for 
this demo code!

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 4/2/25 05:13, ingo wrote:
> >        turbulence: (
> >          strength: (x: 1.6, y: 2.2),
> >          lambda: 2.5,
> >          omega: 0.7,
> >          octaves: 6
> >        )
>
> Interesting. I'm impressed you implemented at 2D perlin turbulence() for
> this demo code!
>
> Bill P.

Sorry to disappoint you, a bit. I scaled down my "old" 3d version to 2d. The 3d
version is used in a slowly growing audio synthesis project where tiles with
patterns are used as the "sound source". I'm not realy happy with the
turbulence yet, it doesn't work as smooth as POV-Ray's implementation.


ingo

Post a reply to this message

"ingo" <nomail@nomail> wrote:
> "Mr" <m******r******at_hotmail_dot_fr> wrote:
> > "ingo" <nomail@nomail> wrote:
> > > "Mr" <m******r******at_hotmail_dot_fr> wrote:
>
> > I don't know enough to have an opinion about using a database oriented POV
> > workflow, which does sound very powerful, but I did have a look at the  overview
> > descriptions of the nim language, and though there are some aspects that I don't
> > naturally enjoy in its syntax, they probably are specifically the ones that
> > every one around here seem to be asking for, also the fact that it can be
> > interpreted and compiled... Well, wouldn't this make it suited to be a scene
> > description language that could get accelerated as a compiled version just
> > before parsing?
>
> Using Nim and a library nimscripter I made a simple image renderer, the way you
> suggested here. Most of the rendering procedures are compiled and are made
> available to the VM so they run at "max" speed. Math functions already run at
> max speed in the VM. This all is then available in the scripting language.
>
> In my little app you can create patterns from math functions and render those.
> You can add POV style like turbulence and gray scale mapping, instead of our
> color_map.
>
> You compile the render engine and then render the .nims scripts with it. Just
> like POV-Ray renders SDL, but without the need for writing a parser etc.
>
> It does work, but it is not a smooth path yet. Not every thing is possible
> (yet?) with this way of creating an app.
>
> https://gist.github.com/ingoogni/8e1f74f8ea7250da778a202648e96e9b
>
> the script for the image:
> ---%<------%<------%<---
> import math
>
> proc sincos(x, y: float): float =
>   return (1 + (sin(x) * cos(y))) * 0.5
>
>
> proc main() =
>
>   var img = initPGM("sincos.pgm")
>   img.gamma = srgb
>
>   let
>     gm = Pattern(
>       funk: sincos,
>       greymap: @[(0.0,0.0),(0.5,0.2),(0.8,0.7),(1.0,0.0)],
>       turbulence: (
>         strength: (x: 1.6, y: 2.2),
>         lambda: 2.5,
>         omega: 0.7,
>         octaves: 6
>       )
>     )
>     width = 640
>     height = 480
>     viewportWidth = 30.0
>     viewportHeight = 0.0
>     #viewportHeight = viewportWidth * (height / width)  # Maintain aspect ratio
>     grid = gm.render(width, height, viewportWidth, viewportHeight)
>
>   img.writePGM(grid)
>
>
> when isMainModule:
>   main()
> ---%<------%<------%<---

The fact that it does work is already a huge achievement ! Ignoring the syntax I
wonder, did you create the previous routines in POV originally? and if so, do
you think there could be a way to compare fairly render times? Should rather
only the parse to render ratio be considered ? with your approach, would
separate builds have to be made afresh for every scene? About the nim script
language, though it is said to have some removed functionality, is it still
"Turing complete" ? ...Meaning, as much as POV/INC sdl?

Post a reply to this message

"Mr" <m******r******at_hotmail_dot_fr> wrote:

> The fact that it does work is already a huge achievement ! Ignoring the syntax I
> wonder, did you create the previous routines in POV originally? and if so, do
> you think there could be a way to compare fairly render times? Should rather
> only the parse to render ratio be considered ? with your approach, would
> separate builds have to be made afresh for every scene? About the nim script
> language, though it is said to have some removed functionality, is it still
> "Turing complete" ? ...Meaning, as much as POV/INC sdl?

The syntax can be adapted using macros. I've not tried it yet, only just started
with macros. But when you look at my code it is quite crude. It will be polished
a bit more.

No, I did it straight in Nim, but I have quite some graphics stuff in Nim to
build from. As render times are concerned, this is currently one thread and I'm
working on a multithreaded version. It's about half way.

Once done I'll compare a similar pattern, but POV-Ray will win as I so far have
no clue how to implement SIMD intrinsics. On my machine that would mean 24
thread each doing one calculation vs. 24 threads each doing ~8 calculations at
once.

One only has to build the renderer.nim once and then you can rewrite and render
many scripts on it without rebuilding.

Yes it is Turing complete, as far as I know. It has a bit of a problem with
pointers and c-libraries. It is a more capable language than POV-Ray SDL. Most
of Nim's "pure" libraries should work in script:
https://github.com/nim-lang/Nim/tree/devel/lib/pure

But, beware, I'm certainly no Nim specialist. Also, there are / must be other
languages that can do this. At least good old LISP can.

ingo

Post a reply to this message

"ingo" <nomail@nomail> wrote:
> "Mr" <m******r******at_hotmail_dot_fr> wrote:
>
> I'm working on a multithreaded version. It's about half way.
>

a 4000x4000 image took 1 minute 7 seconds. Multi threaded works, the same image
takes 2 sec 968 ms.

Next, clean up and polish.

ingo

Post a reply to this message