Shader Preview Panel Dev Question

[appleGuy]

Hi Guys,

After some valuable feedback, I have decided to make a start on the
shader preview panel first.
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.

What do you guys think? If this way is best, does k3d already have a
temp directory where I can read and write these renders from?

Cheers
-Alex

-------------------------------------------------------------------------
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

[hoako]

Hi Alex!

>
> After some valuable feedback, I have decided to make a start on the
> shader preview panel first.
:-) Thanks a lot!
> 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.
Tim should give you the final word, but I believe this is the way to go.
My best tips:
- Add a material property to the panel so that the user choose manually the
material. Later you may resolve choosing it automatically.
- Add an update button, latter it'll change on properties signals.
- You only need the sphere primitive (Create->Quadrics->Sphere) by now, is the
one that has UV mapping.

Also an interesting challenge is canceling the render when the user change any
material (or press update), but that's not necessary right now. (but you can
start a new render anyway and use the new image)

> What do you guys think? If this way is best, does k3d already have a
> temp directory where I can read and write these renders from?
AFIAK there is an API for calling the temp directory.
../k3dsdk/system.cpp:const filesystem::path get_temp_directory()
In fact, renders go there. On linux
/tmp/k3d-renderman-preview

Cheers!
Joaquín


-------------------------------------------------------------------------
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

[appleGuy]

Hi Guys,

Right I have got the File IO part done (using k3d IO of course) -> Needs
to be a bit more robust but will do for now.

The next stage is getting a render (initializing an external render
engine) done using a geometry object.

Now I think the best way of doing this, is to create a new document (one
you wont be able to play with). this document will set up with the
geometry and camera specifics etc. Then k3d render facilities will be
called using the document and the chosen render engine (rEngine
selection bit done).

Put simply can I do this.. create a new document? ... Is this the best
way?.. I could go the root of creating render input files etc, but thats
a lot of work to cover all k3d supported render engines. I may as well
use stuff already provided.

Cheers
Alex

>
> Hi Alex!
>
>  
>> After some valuable feedback, I have decided to make a start on the
>> shader preview panel first.
>>    
> :-) Thanks a lot!
>  
>> 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.
>>    
> Tim should give you the final word, but I believe this is the way to go.
> My best tips:
> - Add a material property to the panel so that the user choose manually the
> material. Later you may resolve choosing it automatically.
> - Add an update button, latter it'll change on properties signals.
> - You only need the sphere primitive (Create->Quadrics->Sphere) by now, is the
> one that has UV mapping.
>
> Also an interesting challenge is canceling the render when the user change any
> material (or press update), but that's not necessary right now. (but you can
> start a new render anyway and use the new image)
>
>  
>> What do you guys think? If this way is best, does k3d already have a
>> temp directory where I can read and write these renders from?
>>    
> AFIAK there is an API for calling the temp directory.
> ../k3dsdk/system.cpp:const filesystem::path get_temp_directory()
> In fact, renders go there. On linux
> /tmp/k3d-renderman-preview
>
> Cheers!
> Joaqu?n
>
>
>
>  

-------------------------------------------------------------------------
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

[hoako]

Alex Curtis wrote:

> Hi Guys,
>
> Right I have got the File IO part done (using k3d IO of course) -> Needs
> to be a bit more robust but will do for now.
>
> The next stage is getting a render (initializing an external render
> engine) done using a geometry object.
>
> Now I think the best way of doing this, is to create a new document (one
> you wont be able to play with). this document will set up with the
> geometry and camera specifics etc. Then k3d render facilities will be
> called using the document and the chosen render engine (rEngine
> selection bit done).
>
> Put simply can I do this.. create a new document? ... Is this the best
> way?.. I could go the root of creating render input files etc, but thats
> a lot of work to cover all k3d supported render engines. I may as well
> use stuff already provided.

Hi again!

You should evaluate performance. I guess you mean creating one document and
modifying it, but not creating a new document each time the user changes something.

What I would do is generating the material in the original document and hack the
  render settings of the new document to used this material created. Instead of
trying to migrate the whole material to the new document. (well, i guess this
could by heavy on certain cases)

I don't know if you should hack the RenderManEngine node or the
AqsisRenderManEngine.

Let's see Tims opinion.

Cheers!
Joaquín


-------------------------------------------------------------------------
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

[appleGuy]

Hi,

Thinking about this ...

I think the best way of doing this is to create nodes such as camera,
geometry during the creation of the panel.. Then remove these nodes from
the current document when the panel is closed. This way I can use the
same document.

Then the shader preview render can use this camera and geometry. I might
even create a render engine node.. another question: where in the source
is the renderman engine node. Not the actual render_engine (aqsis etc)
but the node that holds a selected render engine, resolution etc

If this is a good idea. How do i go about creating these nodes like a
new camera and a new quadratic object.. Maybe im not thinking straight
because it is late :(

Many Thanks
-Alex


Alex Curtis wrote:

> Hi Guys,
>
> Right I have got the File IO part done (using k3d IO of course) ->
> Needs to be a bit more robust but will do for now.
>
> The next stage is getting a render (initializing an external render
> engine) done using a geometry object.
>
> Now I think the best way of doing this, is to create a new document
> (one you wont be able to play with). this document will set up with
> the geometry and camera specifics etc. Then k3d render facilities will
> be called using the document and the chosen render engine (rEngine
> selection bit done).
>
> Put simply can I do this.. create a new document? ... Is this the best
> way?.. I could go the root of creating render input files etc, but
> thats a lot of work to cover all k3d supported render engines. I may
> as well use stuff already provided.
>
> Cheers
> Alex
>
>>
>> Hi Alex!
>>
>>  
>>> After some valuable feedback, I have decided to make a start on the
>>> shader preview panel first.
>>>    
>> :-) Thanks a lot!
>>  
>>> 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.
>>>    
>> Tim should give you the final word, but I believe this is the way to go.
>> My best tips:
>> - Add a material property to the panel so that the user choose
>> manually the material. Later you may resolve choosing it automatically.
>> - Add an update button, latter it'll change on properties signals.
>> - You only need the sphere primitive (Create->Quadrics->Sphere) by
>> now, is the one that has UV mapping.
>>
>> Also an interesting challenge is canceling the render when the user
>> change any material (or press update), but that's not necessary right
>> now. (but you can start a new render anyway and use the new image)
>>
>>  
>>> What do you guys think? If this way is best, does k3d already have a
>>> temp directory where I can read and write these renders from?
>>>    
>> AFIAK there is an API for calling the temp directory.
>> ../k3dsdk/system.cpp:const filesystem::path get_temp_directory()
>> In fact, renders go there. On linux
>> /tmp/k3d-renderman-preview
>>
>> Cheers!
>> Joaqu?n
>>
>>
>>
>>  
>
>

-------------------------------------------------------------------------
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

[Timothy M. Shead]

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

[Timothy M. Shead]

Joaquín Duo wrote:
> - You only need the sphere primitive (Create->Quadrics->Sphere) by now, is the
> one that has UV mapping.
>  
To clarify, the preview panel can start-out simply generating its own
RIB without using any other plugins.  A later refinement would be to use
user-defined geometry for previewing.

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

[Timothy M. Shead]

Alex Curtis wrote:

> Right I have got the File IO part done (using k3d IO of course) -> Needs
> to be a bit more robust but will do for now.
>
> The next stage is getting a render (initializing an external render
> engine) done using a geometry object.
>
> Now I think the best way of doing this, is to create a new document (one
> you wont be able to play with). this document will set up with the
> geometry and camera specifics etc. Then k3d render facilities will be
> called using the document and the chosen render engine (rEngine
> selection bit done).
>
> Put simply can I do this.. create a new document? ... Is this the best
> way?.. I could go the root of creating render input files etc, but thats
> a lot of work to cover all k3d supported render engines. I may as well
> use stuff already provided.
>  

I sort-of alluded to this in my reply to your earlier question.  The
answer is that yes, you *can* create a "hidden" document and use it in
this way, but I don't think you want to (I'm willing to hear
counterarguments).  The issue is that it is reasonable to (eventually)
give the user control over what happens - what sort of primitive to
render with (sphere, cylinder, plane, user-specified geometry) and how
to render (choice of render engine, details affecting quality /
performance tradeoffs, etc).  As soon as you start giving the user that
control, they won't want to have to reproduce all their choices every
time they start the program.  That means serialization, which may as
well be in the same document the user is working-on.  After all, if they
*are* going to provide user-specified geometry for previewing, that
geometry has to come from somewhere, and it logically ought to come from
the current document.  Same for all the hundreds of render-engine
parameters that are available.  So I really do see your panel as working
with the contents of the current doc.

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

[Timothy M. Shead]

Alex Curtis wrote:

> I think the best way of doing this is to create nodes such as camera,
> geometry during the creation of the panel.. Then remove these nodes from
> the current document when the panel is closed. This way I can use the
> same document.
>
> Then the shader preview render can use this camera and geometry. I might
> even create a render engine node.. another question: where in the source
> is the renderman engine node. Not the actual render_engine (aqsis etc)
> but the node that holds a selected render engine, resolution etc
>
> If this is a good idea. How do i go about creating these nodes like a
> new camera and a new quadratic object.. Maybe im not thinking straight
> because it is late :(
>  

Yep, this is the right approach.  I'd make one refinement, which is that
you should only create the preview-related nodes when you need them, not
when the panel is created, and you don't need to delete them when the
panel is closed.  That way, users can make changes to them and have them
persist across sessions.

See modules/renderman/render_engine.cpp for the RenderManEngine node
that encapsulates parameters that are standard across different
implementations.

See modules/renderman_engines for the implementation-specific nodes that
handle shader-compilation and final rendering.

You can simply use the k3d::plugin::create() overloads to add nodes to a
document.

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

[hoako]

Timothy M. Shead wrote:
> I sort-of alluded to this in my reply to your earlier question.  The
> answer is that yes, you *can* create a "hidden" document and use it in
> this way, but I don't think you want to (I'm willing to hear
> counterarguments).  The issue is that it is reasonable to (eventually)
This is what i find:
-The only problem i find is adding "not so interesting" objects to the whole scene.
The camera could have a painter, so assigning no painter could be a solution
(its already there for objects). Or could be generated on the fly before the
rendering.(the same for lights)
Also lights will appear on RenderManEngine node under the Enabled Lights property.

On the other hand Node List Panel could have a new version where the user only
see a hierarchy of nodes. Also layers could be implemented, so there could be a
Material Scene layer, which is not affected by the hide/show commands, and other
commands.
But I don't know if this is the right approach, instead of serializing a new
document and embedding it on the original. Furthermore, the user could use an
instance of K-3D to edit this new environment in case s/he wants to.
What do you think?

Cheers!
Joaquín!


-------------------------------------------------------------------------
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

[Timothy M. Shead]

Joaquín Duo wrote:

> Timothy M. Shead wrote:
>  
>> I sort-of alluded to this in my reply to your earlier question.  The
>> answer is that yes, you *can* create a "hidden" document and use it in
>> this way, but I don't think you want to (I'm willing to hear
>> counterarguments).  The issue is that it is reasonable to (eventually)
>>    
> This is what i find:
> -The only problem i find is adding "not so interesting" objects to the whole scene.
>  

Anything that needs to be saved must be part of the document.  If you
don't want to see it, that's an orthogonal issue.

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

[hoako]

Timothy M. Shead wrote:

> Joaquín Duo wrote:
>> Timothy M. Shead wrote:
>>  
>>> I sort-of alluded to this in my reply to your earlier question.  The
>>> answer is that yes, you *can* create a "hidden" document and use it in
>>> this way, but I don't think you want to (I'm willing to hear
>>> counterarguments).  The issue is that it is reasonable to (eventually)
>>>    
>> This is what i find:
>> -The only problem i find is adding "not so interesting" objects to the whole scene.
>>  
> Anything that needs to be saved must be part of the document.  If you
> don't want to see it, that's an orthogonal issue.

:-)
To clarify: My point was if the code hiding this objects and modifying them was
more complicated than creating a new document(editing it on a different
instance) and embedding it into the original document like images are inlined.

Cheers!
Joaquín


-------------------------------------------------------------------------
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