POV-Ray : Newsgroups : povray.advanced-users : Classes/containers in sdl? : Re: Classes/containers in sdl? Server Time
28 Apr 2024 08:52:01 EDT (-0400)
  Re: Classes/containers in sdl?  
From: INVALID ADDRESS
Date: 16 Nov 2016 18:20:36
Message: <1802475221.501030102.916802.gdsHYPHENentropyAThotmaolDOTcom@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:
> 
> As a matter of fact, an inbuilt JSON import feature also already exists
> in the same drawer the variable-type arrays reside in (not a
> coincidence; my idea is to convert the JSON data directly into a
> corresponding hierarchy of SDL containers, but this requires that arrays
> can hold variable types), as part of an effort to import DAZ Studio DSON
> material definitions.
> 
 
I am glad I asked then! :D

It would be very cool to be able to import DAZ materials, even though I
have somewhat against them for their neglect of Bryce and Carrara, and
Hexagon frankly. I have all 3 on my dedicated gfx box (the Xeon machine).

One of my favorite web comics is actually made with Carrara and started in
Bryce: Requiem. Great plot, and the author is a software and graphics guy
like most of us.

One bit of irritation I have with arrays is that you cant do this:

#declare myArray = array[foo][bar];

// loop
#local etc = myArray[iterator];

And similar with assignment.

I ended up making a 1d array of 1d arrays. Its just more code to do pretty
much the same thing, and isn't really intuitive to those used to and coming
from other languages.

I think some concessions to the way many of the popular languages work,
like JS, Java and C# would be beneficial, with regard to array behavior.

I also noticed that I cannot do the following:
Short-circuit conditional ops (shocked me)
Unary modification and assignment (+= and so forth)

I had been away from SDL so long these facts took me aback. I assume there
are very good reasons for this, because they are so common if not for such
they would have been implemented already.

It would be very cool if, as part of the refactor toward modularization,
that the SDL were abstracted and facaded from the engine, so that ANY SDL
which meets the required interface specification could then be used, which
would likely simplify inclusion of Pov as a 3rd party rendering option.
Frankly you could leave the internal SDL coding and just facade
that...though that would be less ideal from an architectural standpoint
than a purpose built generic DSL interpreter, but also far less work and so
maybe a good "phase 1" go of it.

I had once tried to hook into Pov so that I could invoke the render and
host the output in a C# app picturebox, but I never figured out how. Moray
does it so it is obviously possible, but I don't know how much of a hack
their method was or if there is some actual API for this.

I would like to do this as part of the rework of my Image2Pov texture
creation app, the one that produces extremely realistic agates, marbles and
such from colors harvested from images.

Ian


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.