>
> Indeed.  I haven't looked too much at the parser and the tokenizing of things,
> but I would imagine that every object defined in SDL would have to have some
> unique identifier of one sort or another.  It would be great to discover what
> that is, and have an SDL-accessible table of numbered objects and associated
> attributes.
>
> I really have no top-down overview of how everything happens in order to go from
> the simplest of scenes to defining the final rgb values of a pixel in a render.
> It would be great to make a flowchart, perhaps with one of those automated
> software-analyzing packages...
>
> I guess just start by looking at:
> povray/source/core/shape/mesh.cpp
>
> and see if anything pops out at you

You can specify objects and object identifiers in SDL...there are ways to hook
into the parser so that you can get an "object pointer" when an object
definition of object identifier shows up in the scene. It may be that it's
possible given the object pointer to figure out that the top level object is a
mesh, and get the mesh data. I will definitely be looking into that at some
point. (My priority at the moment is cleaning up the code and implementing an
easy way to tweak calls to the minimum distance function easily in SDL).

It is unclear whether that helps with performance of a minimum distance
function, but one thing it *would* be useful for is testing, to evaluate how
accurate various methods are. Of course, I can also evaluate that stuff using
other methods, as well, since I know the mesh definition "offline" already.

>
> > Yeah, a "developer's guide to patching povray" would be great. 😁
> >
> > I could possible post some details about how to add keywords and get them
> > processed, but it would only really be useful to folks that have a compiler and
> > know how to use it.
>
> There are a few of us who have compilers, being on linux machines, but I usually
> need a bit of hand-holding to build pov-ray from scratch and install it.  ;)
>
> I think it also comes down to a sort of chicken-and-egg thing, where people have
> reason to use their compiler, so they don't know how, and so they don't do
> anything with them.
>
> I can kinda read _most_ of the source code, but there are certain notations and
> other things going on that I'm still ignorant of, and therefore remain cryptic.
> I've dabbled, and spent quite a while programming several arduino boards for
> various different purposes.   Which is "C++".

I could probably help anyone trying to patch/build/run on windows using visual
studio 2015, I don't know what wrinkles might be involves in doing it in Linux,
Mac, etc.

Post a reply to this message