Alex Curtis wrote:
> Hi Guys,
>
> After some valuable feedback, I have decided to make a start on the
> shader preview panel first.
>
Reasonable choice.
> At this moment in time all the gui and storage / organisation ground
> work is pretty much there. I am now focusing on the actual process of
> rendering the shader previews and displaying the result.
>
> The only way I can think of doing this is to simply call the renderer.
> store the resulting image in a (possibly hidden) temporary file in the
> k3d working directory. Then source the preview display image from this
> file. Repeating this process every time a shader or shader selection
> changes.
>
One detail worth considering is how you plan to render. You could use
an existing RenderManEngine object from the user's current document, or
you could call the implementation-specific objects directly. You might
want to consider having some logic that would create a RenderManEngine
with sensible defaults for previewing, if it doesn't already exist in a
document.
A different alternative worth considering would be to create a
render-engine plugin that embeds Aqsis directly, allowing you to pass
data to it in-memory instead of going to a file. We've talked about
this for years, it's up-in-the-air whether it would provide enough
reduction in latency to be worth the effort.
Cheers,
Tim
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development
