For everyones general information, I think bounties like this are a great
way not only to get new features, but most especially to say "thanks" to
the folks who put in work making PovRay what it is.

I am very excited for the opportunities this opens up for everyone.

Once this feature is in I want to look at true displacement, which will be
a ton of work and I won't be able to fund it alone. I think TD would buy a
lot for both the package and the community as a whole.

There was at least one PovRay modification that supported  true
displacement, but the way it was accomplished was to make Pov conform to
some degree with the Renderman SL standard, and if I recall correctly it
broke entirely with the way pov handles materials (not the pov term, but
general).

It is dead but the source lives on courtesy of Archive.org:
https://web.archive.org/web/20090103185310/http://www.aetec.ee/fv/vkhomep.nsf/pages/povman2

Povman is based on MP 1.1, and Vahur Krouverk was the author.

Obviously we would want to keep the way pov handles materials in SDL, but
also allow true displacement as seen in Renderman. I don't know what this
would entail specifically but I would feel safe betting it would be
nontrivial work.

I am not advocating full RM spec compliance, only hijacking the
displacement code from PovMan in some form, preferably without having to
use a shader compiler.

I would like to know how many folks would like to see true displacement
ported over because like I said I can't fund that one alone (at least not
in a single shot).

If there isn't much interest (which frankly would shock me) then it
wouldn't even be worth trying to size the work...but conversely if the
interest is great, then there may be some merit at least in investigation
of the idea.

Other things which might be useful:

- OpenCL/GPU. This has been talked to death but because of the complexity
perhaps a large enough bounty would be sufficiently motivating and provide
a good ROI for the team.

- A reasonable alternative to GPU raytracing is "progressive raytracing", a
quick google search even gets you articles stating that this is far less
complex to do than GPU but is much faster than normal RT and is advocated
as either an alternative to GPU RT or an intermediate point between normal
RT and a GPU implementation.

- Ability to "scan" objects into a distance based resolution adaptive mesh
instead of rendering the object as normal, which might speed up render. (I
know marching triangles macros exist, would an internal implementation be
faster?)

- Navier-Stokes flow, compressible and incompressible implemented as a
primitive. So if you place the primitive in a hollow hemisphere it would
naturally fill it, or if you put it in a HF valley with rocks and such it
would fill it to the Y position of the primitive and "flow" around the
rocks, making eddies and ripples and such. Flow direction would be a
vector, fluid would naturally fill whatever was around it as well.

- Enhancements to volumetric rendering, so media behaves
consistently/predictably regardless of container volume and/or scale. Right
now making a good looking variable density fog or cloud can get a bit weird
and it is difficult to predict the outcome of any given input. Having some
kind of distance based resolution may enhance speed as well. Perhaps the
volumetric rendering task can be sent to the GPU alone. 

- Implement a plugin based architecture for pov, so new features could be
added without having to rework the whole application each time. I have
solved many problems using plugin based architecture, and am quite a fan of
it. If done correctly this might allow Pov to get more features faster, but
would take a lot of work to do initially.

Ian

Post a reply to this message