k3d-development

[K3d-development] Textures, again

[Anders S. <and...@gm...>]

Hey

Back on track for a while again, so I thought I'd try to get some
things done with texturing. Just a couple of questions before moving
on:

First, I'm thinking it'd be interesting to show a manipulator when a
certain modifier node ("planar_mapping" in this case) is selected.
Kind of like a tool activated by the node. Would that be possible
somehow? I'm guessing it'd have to be the tool in that case monitoring
when it should activate, since otherwise the node would be dependent
on ngui which feels wrong. Does this all sound like a bad idea, and if
not is it currently possible?

Second, I'm not totally sure how to preview textures (and in the not
so much longer run other material specific things) in the viewport due
to a couple of issues. For example, a RenderManMaterial doesn't have
any obvious way to render itself in the viewport. The painter can't
currently know which texture to use and with which texcoord set, etc.
The same would go for any custom materials added, etc. In Maya, this
is solved by materials being able to override drawing methods that
renders the object instead of the default drawer. I suggest something
similar is done here, by having materials (optionally) implement an
interface that the painter can check for. This interface could either
be to query data about how to render the material (easy to implement
on the client/material side) or to pass "control" over the rendering
to the material (slightly more implementation work on the material
side and more error prone, but a lot more flexible).

Finally, there doesn't seem to be anything like a "OpenGLTextureMap"
node or so. This would be easy to add, similar to the
"RenderManTextureMap", do you think that's the way to go? The downside
of that textures that are used both for rendering & viewport preview
would need two nodes for one bitmap. Not sure how you want this to be
handled.

Any input? :)
/Anders

Re: [K3d-development] Textures, again

[Joaquín D. <hoa...@ya...>]

Anders Stenberg wrote:
> Hey
> 
> Back on track for a while again, so I thought I'd try to get some
> things done with texturing. Just a couple of questions before moving
> on:
> 
> First, I'm thinking it'd be interesting to show a manipulator when a
> certain modifier node ("planar_mapping" in this case) is selected.
> Kind of like a tool activated by the node. Would that be possible
> somehow? I'm guessing it'd have to be the tool in that case monitoring
> when it should activate, since otherwise the node would be dependent
> on ngui which feels wrong. Does this all sound like a bad idea, and if
> not is it currently possible?
AFAIK Tim was working on manipulators, and i think they aren't finished, but Tim 
should confirm this.

The ideal is that almost any plugin should have a manipulator (like the sphere 
below) So i guess this will be tackled in the same way the Morph_plugin panel 
can have a special treatment.
In my point of view in the future for the sphere the developer should create a 
ngui manipulators that uses a three vector (or point) as input property, process 
it on a method and as a result you have the radius value, u and v segments, for 
example. (one gives the position, the second vector gives the size and the x and 
y coordinates of the other gives you the u and v segments, of course the 
combinations of inputs are unlimited for the same output)
Here you can see some sketches on manipulators for primitives (quite crappy)
http://www.k-3d.org/wiki/User:JoaquinDuo/Manipulators

For prototyping manipulators you could use a script like the one I used for an 
sphere, check here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1890113&group_id=11113&atid=311113

For mapping i would use as input:
1- One matrix4 for position, size and orientation (or better splitting this 
information?)
2- Type of mapping: planar, spherical, cube, cylindrical (another one?)

Then you can connect your script to send signals to the mapping node.

Cheers!
Joaquín

Re: [K3d-development] Textures, again

[Daniel S. M. <dsm...@gm...>]

On Sat, Jun 21, 2008 at 6:43 AM, Anders Stenberg
<and...@gm...> wrote:
> Hey
>
> Back on track for a while again, so I thought I'd try to get some
> things done with texturing. Just a couple of questions before moving
> on:
>
> First, I'm thinking it'd be interesting to show a manipulator when a
> certain modifier node ("planar_mapping" in this case) is selected.
> Kind of like a tool activated by the node. Would that be possible
> somehow? I'm guessing it'd have to be the tool in that case monitoring
> when it should activate, since otherwise the node would be dependent
> on ngui which feels wrong. Does this all sound like a bad idea, and if
> not is it currently possible?
>
> Second, I'm not totally sure how to preview textures (and in the not
> so much longer run other material specific things) in the viewport due
> to a couple of issues. For example, a RenderManMaterial doesn't have
> any obvious way to render itself in the viewport. The painter can't
> currently know which texture to use and with which texcoord set, etc.
> The same would go for any custom materials added, etc. In Maya, this
> is solved by materials being able to override drawing methods that
> renders the object instead of the default drawer. I suggest something
> similar is done here, by having materials (optionally) implement an
> interface that the painter can check for. This interface could either
> be to query data about how to render the material (easy to implement
> on the client/material side) or to pass "control" over the rendering
> to the material (slightly more implementation work on the material
> side and more error prone, but a lot more flexible).
>
> Finally, there doesn't seem to be anything like a "OpenGLTextureMap"
> node or so. This would be easy to add, similar to the
> "RenderManTextureMap", do you think that's the way to go? The downside
> of that textures that are used both for rendering & viewport preview
> would need two nodes for one bitmap. Not sure how you want this to be
> handled.
>
> Any input? :)
> /Anders
>

This is why in the past I have mentioned the importance of texture
baking. A Renderman texture can be baked into a preview bitmap so that
it can be displayed in the viewport and assist in map editing (scale,
rotation, position) operations. We would need to look at the shaders
so that those operations that relate to SL variables can be linked.
i.e. You can change some mapping related parameters for the node
without the texture requiring a rebake and the preview bitmap used by
the viewport just has new transforms applied to it.

Having the shader language to bitmap function implemented on the
graphics card could make it a lot faster and it ran in the background
it would minimize the impact of the calculation time required. A
skilled user would set up their shaders with reuse of the baked
texture in mind, but this may require splitting the transforms from
the pixels in the bitmap as different object would need to scale the
texture differently. e.g. a pile of rocks would all use the same
prebaked texture but the transforms on the texture for each rock would
be different.

>From a user point of view I don't want to have to think about this
more than I need to, I'd rather the GUI set things up for me when I
create a new material or reference an existing one.

Re: [K3d-development] Textures, again

[Timothy M. S. <ts...@k-...>]

Anders Stenberg wrote:
> First, I'm thinking it'd be interesting to show a manipulator when a
> certain modifier node ("planar_mapping" in this case) is selected.
> Kind of like a tool activated by the node. Would that be possible
> somehow? I'm guessing it'd have to be the tool in that case monitoring
> when it should activate, since otherwise the node would be dependent
> on ngui which feels wrong. Does this all sound like a bad idea, and if
> not is it currently possible?
>   
Seems like a really good idea, and you have the right instincts - the UI 
layer would be responsible for activating the tool when the node is 
selected.  This is a good use-case for plugin metadata, which would be 
used to "mark" the tool plugin so the UI knows to activate it.
> Second, I'm not totally sure how to preview textures (and in the not
> so much longer run other material specific things) in the viewport due
> to a couple of issues. For example, a RenderManMaterial doesn't have
> any obvious way to render itself in the viewport. The painter can't
> currently know which texture to use and with which texcoord set, etc.
> The same would go for any custom materials added, etc. In Maya, this
> is solved by materials being able to override drawing methods that
> renders the object instead of the default drawer. I suggest something
> similar is done here, by having materials (optionally) implement an
> interface that the painter can check for. This interface could either
> be to query data about how to render the material (easy to implement
> on the client/material side) or to pass "control" over the rendering
> to the material (slightly more implementation work on the material
> side and more error prone, but a lot more flexible).
>   
Actually, the painter *does* have access to all material information, 
including choice-of-texture - each gprim (curve group, face, patch, etc) 
has an imaterial* that is your handle to this information.  There's some 
complexity there in terms of "walking the tree" to get the info you 
need, but it's all there.

My experience is that having a material "render itself" is only useful 
in the simplest of cases - in general, there isn't a meaningful 
distinction to be made between "material" and "rendering" - the two are 
almost always strongly coupled (at least in OpenGL).  As an example, a 
very simple material property - transparency - requires a complex 
multi-pass rendering algorithm: the material can't just setup some 
OpenGL state and then hand things off for rendering.  The intent of the 
current design is that all rendering - which includes material setup - 
is handled by painters.
> Finally, there doesn't seem to be anything like a "OpenGLTextureMap"
> node or so. This would be easy to add, similar to the
> "RenderManTextureMap", do you think that's the way to go? The downside
> of that textures that are used both for rendering & viewport preview
> would need two nodes for one bitmap. Not sure how you want this to be
> handled.
>   
Welllll, the reason we have a RenderManTextureMap is to provide a place 
to store all the parameters that RenderMan allows for textures - wrap, 
filter type, filter width, etc.  I guess that if we expanded 
OpenGLMaterial to include texture-map data, we might do something similar.

Cheers,
Tim

Re: [K3d-development] Textures, again

[Anders S. <and...@gm...>]

Joaquin, I agree about the manipulators. In Maya (which you by now
know I compare to a lot) different things like planar mapping,
deformers, etc, have manipulators (hrough its tool interface, which
means these disappear when the tool is switched, and you can't get
them back again (as far as I know) bound to the same modifier node.
This is really annoying, and I'd like some solution where, as
mentioned, the manipulator appears whenever the modifer is selected.
I'll have a look at your script, but I'm having trouble running
scripts for some reason. Need to look into that.

Daniel, baking is really great and could be a good idea for ShaderMan
materials. However, it's a bit limited in what it can do. Let's say
you want to hook up a game engine to K-3D and in the viewport see how
it's going to look in the game. Then you'll most probably need
something more than baking. (But yes, it's something I think should be
there, but I'm not going to do it. At least not now. ;)

Tim, can you elaborate on the metadata? Also, can you give any more
pointers about iMaterial? The only iMaterial interfaces I can find
seem very empty?
About "rendering itself", I agree. While it's possible in Maya to do
cool stuff fairly easily, as soon as you need more control than just
object local (for multipass, shadows, etc..) you're in trouble. Still,
the material will need to somehow communicate how it wants itself to
be rendered to the painter. As I mentioned, please give me some more
pointers to how this is currently done if there already is such
functionality.

About both RenderManTextureMap and a possible OpenGLTextureMap... As
Daniel said, it probably doesn't matter much as long as the GUI
handles hooking up the intermediate nodes.

/Anders

On Sun, Jun 22, 2008 at 6:50 AM, Timothy M. Shead <ts...@k-...> wrote:
> Anders Stenberg wrote:
>> First, I'm thinking it'd be interesting to show a manipulator when a
>> certain modifier node ("planar_mapping" in this case) is selected.
>> Kind of like a tool activated by the node. Would that be possible
>> somehow? I'm guessing it'd have to be the tool in that case monitoring
>> when it should activate, since otherwise the node would be dependent
>> on ngui which feels wrong. Does this all sound like a bad idea, and if
>> not is it currently possible?
>>
> Seems like a really good idea, and you have the right instincts - the UI
> layer would be responsible for activating the tool when the node is
> selected.  This is a good use-case for plugin metadata, which would be
> used to "mark" the tool plugin so the UI knows to activate it.
>> Second, I'm not totally sure how to preview textures (and in the not
>> so much longer run other material specific things) in the viewport due
>> to a couple of issues. For example, a RenderManMaterial doesn't have
>> any obvious way to render itself in the viewport. The painter can't
>> currently know which texture to use and with which texcoord set, etc.
>> The same would go for any custom materials added, etc. In Maya, this
>> is solved by materials being able to override drawing methods that
>> renders the object instead of the default drawer. I suggest something
>> similar is done here, by having materials (optionally) implement an
>> interface that the painter can check for. This interface could either
>> be to query data about how to render the material (easy to implement
>> on the client/material side) or to pass "control" over the rendering
>> to the material (slightly more implementation work on the material
>> side and more error prone, but a lot more flexible).
>>
> Actually, the painter *does* have access to all material information,
> including choice-of-texture - each gprim (curve group, face, patch, etc)
> has an imaterial* that is your handle to this information.  There's some
> complexity there in terms of "walking the tree" to get the info you
> need, but it's all there.
>
> My experience is that having a material "render itself" is only useful
> in the simplest of cases - in general, there isn't a meaningful
> distinction to be made between "material" and "rendering" - the two are
> almost always strongly coupled (at least in OpenGL).  As an example, a
> very simple material property - transparency - requires a complex
> multi-pass rendering algorithm: the material can't just setup some
> OpenGL state and then hand things off for rendering.  The intent of the
> current design is that all rendering - which includes material setup -
> is handled by painters.
>> Finally, there doesn't seem to be anything like a "OpenGLTextureMap"
>> node or so. This would be easy to add, similar to the
>> "RenderManTextureMap", do you think that's the way to go? The downside
>> of that textures that are used both for rendering & viewport preview
>> would need two nodes for one bitmap. Not sure how you want this to be
>> handled.
>>
> Welllll, the reason we have a RenderManTextureMap is to provide a place
> to store all the parameters that RenderMan allows for textures - wrap,
> filter type, filter width, etc.  I guess that if we expanded
> OpenGLMaterial to include texture-map data, we might do something similar.
>
> Cheers,
> Tim
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> K3d-development mailing list
> K3d...@li...
> https://lists.sourceforge.net/lists/listinfo/k3d-development
>

Re: [K3d-development] Textures, again

[Timothy M. S. <ts...@k-...>]

Anders Stenberg wrote:
> Tim, can you elaborate on the metadata?
>   
I've updated the documentation at

http://www.k-3d.org/wiki/Plugin_Metadata
http://www.k-3d.org/wiki/Node_Metadata
http://www.k-3d.org/wiki/Property_Metadata

to provide more practical details.  In your case, we already mark tool 
plugins with a metadata name-value pair of "ngui:component-type" "tool" 
which is how the UI layer knows that they are tools.  We might add 
something along the lines of "ngui:tool-auto-node-activate" "plugin 
type" to let the UI know that when a plugin of the given type is 
selected, the corresponding tool should automatically be activated.

For those who are paying close attention, the reason we would do this 
through metadata and not an interface is that there is a chicken-and-egg 
problem with interfaces - you can't query a tool for an interface unless 
you've already created an instance of it, negating the value of 
on-demand plugin loading.

Cheers,
Tim

Re: [K3d-development] Textures, again

[Anders S. <and...@gm...>]

> Also, can you give any more
> pointers about iMaterial? The only iMaterial interfaces I can find
> seem very empty? [...] Still,
> the material will need to somehow communicate how it wants itself to
> be rendered to the painter. As I mentioned, please give me some more
> pointers to how this is currently done if there already is such
> functionality.

Just bumping this question :)

/Anders

Re: [K3d-development] Textures, again

[Timothy M. S. <ts...@k-...>]

Anders Stenberg wrote:
>> Also, can you give any more
>> pointers about iMaterial? The only iMaterial interfaces I can find
>> seem very empty? [...] Still,
>> the material will need to somehow communicate how it wants itself to
>> be rendered to the painter. As I mentioned, please give me some more
>> pointers to how this is currently done if there already is such
>> functionality.
>>     
> Just bumping this question :)
>   
Sorry about that, I got distracted ... this is one of the trickier parts 
of the system, so I've done some reorganization in the wiki to try and 
address your questions - take a look at

http://www.k-3d.org/wiki/Render_Models

and

http://www.k-3d.org/wiki/Material_Design

and let me know what I've left out.

Cheers,
Tim

Re: [K3d-development] Textures, again

[Anders S. <and...@gm...>]

> Sorry about that, I got distracted ... this is one of the trickier parts
> of the system, so I've done some reorganization in the wiki to try and
> address your questions - take a look at
>
> http://www.k-3d.org/wiki/Render_Models
>
> and
>
> http://www.k-3d.org/wiki/Material_Design
>
> and let me know what I've left out.
>


I read this through, and I agree on most parts. It's got a lot of good
ideas. The thing I miss and that I kind of need to figure out is...
While the OpenGL render model is separate from the other render
models, it still has a connection due to it being the editing
renderer. When you manipulate textures or lights or whatever you'll
want a fair preview of what's happening in the viewport. Of course you
can't match the final output in most cases, and (as noted in the
Render_Models page) it's not even really desirable since it might just
add more clutter, but still you'll often want to be able to see some
kind of output. I'm not sure how this info should be communicated. One
way would be to have some property that materials may provide that the
GL painter could understand (e.g. "preview_texture", "preview_color",
etc). Another would be to have some kind of connection between
materials and a OpenGLMaterial, all in a MultiMaterial. Yet another
would be to just have just the current stuff (with a slightly better
OpenGLMaterial) and leave it to the Artist.

Any ideas?
/Anders

Re: [K3d-development] Textures, again

[Timothy M. S. <ts...@k-...>]

Anders Stenberg wrote:
>> http://www.k-3d.org/wiki/Render_Models
>> http://www.k-3d.org/wiki/Material_Design
>>     
> While the OpenGL render model is separate from the other render
> models, it still has a connection due to it being the editing
> renderer. When you manipulate textures or lights or whatever you'll
> want a fair preview of what's happening in the viewport. Of course you
> can't match the final output in most cases, and (as noted in the
> Render_Models page) it's not even really desirable since it might just
> add more clutter, but still you'll often want to be able to see some
> kind of output. I'm not sure how this info should be communicated. One
> way would be to have some property that materials may provide that the
> GL painter could understand (e.g. "preview_texture", "preview_color",
> etc). Another would be to have some kind of connection between
> materials and a OpenGLMaterial, all in a MultiMaterial. Yet another
> would be to just have just the current stuff (with a slightly better
> OpenGLMaterial) and leave it to the Artist.
>   
I think that there are several distinct OpenGL use-cases:

* Rendering for modeling & scene setup.
* Rendering for technical illustration, informatics, and scientific 
visualization.
* Rendering previews for offline render-engines.
* Rendering high-quality final output using OpenGL.

The first use-case is basically there already, in the sense that we 
provide special capabilities (such as the headlight) that are specific 
to editing.

The second use-case requires more control over the rendered scene, but 
is intended to provide insight into data rather than simulating "real 
life".  I've done a couple of projects that feel into this category.  I 
envision that this is the case where the (currently ignored) 
OpenGLMaterial and (hypothetical) OpenGLLight nodes would be used.

The third use-case is where we would try to reproduce the output of a 
RenderMan / Yafray / Foo render engine.  For this case I *wouldn't* 
provide any preview-specific fields in the objects, nor special material 
or light objects, since the point is to preview the artists' existing 
choices.  There would probably be a separate render engine in this case 
- as an example, the engine would be the right place to implement 
depth-peeling for accurate transparency.  There might be a corresponding 
set of painters, or it might all be self-contained, I don't really know.

The fourth use-case would definitely require separate render engine, 
material, and light nodes specific to the model.  The sky's the limit 
here, since the model would be defined by us, and only limited by what 
we could dream-up for OpenGL.

Assuming that what you're really interested in is use-case 3, I think 
the place to start would be to create a new painter that "understands" a 
RenderMan material and makes some attempt at duplicating it, e.g. 
rendering textures.

Cheers,
Tim

-- 
Timothy M. Shead, K-3D founder
http://www.k-3d.org

Re: [K3d-development] Textures, again

[Anders S. <and...@gm...>]

On Sat, Jun 28, 2008 at 7:06 AM, Timothy M. Shead <ts...@k-...> wrote:
> Anders Stenberg wrote:
>>> http://www.k-3d.org/wiki/Render_Models
>>> http://www.k-3d.org/wiki/Material_Design
>>>
>> While the OpenGL render model is separate from the other render
>> models, it still has a connection due to it being the editing
>> renderer. When you manipulate textures or lights or whatever you'll
>> want a fair preview of what's happening in the viewport. Of course you
>> can't match the final output in most cases, and (as noted in the
>> Render_Models page) it's not even really desirable since it might just
>> add more clutter, but still you'll often want to be able to see some
>> kind of output. I'm not sure how this info should be communicated. One
>> way would be to have some property that materials may provide that the
>> GL painter could understand (e.g. "preview_texture", "preview_color",
>> etc). Another would be to have some kind of connection between
>> materials and a OpenGLMaterial, all in a MultiMaterial. Yet another
>> would be to just have just the current stuff (with a slightly better
>> OpenGLMaterial) and leave it to the Artist.
>>
> I think that there are several distinct OpenGL use-cases:
>
> * Rendering for modeling & scene setup.
> * Rendering for technical illustration, informatics, and scientific
> visualization.
> * Rendering previews for offline render-engines.
> * Rendering high-quality final output using OpenGL.
>
> The first use-case is basically there already, in the sense that we
> provide special capabilities (such as the headlight) that are specific
> to editing.
>
> The second use-case requires more control over the rendered scene, but
> is intended to provide insight into data rather than simulating "real
> life".  I've done a couple of projects that feel into this category.  I
> envision that this is the case where the (currently ignored)
> OpenGLMaterial and (hypothetical) OpenGLLight nodes would be used.
>
> The third use-case is where we would try to reproduce the output of a
> RenderMan / Yafray / Foo render engine.  For this case I *wouldn't*
> provide any preview-specific fields in the objects, nor special material
> or light objects, since the point is to preview the artists' existing
> choices.  There would probably be a separate render engine in this case
> - as an example, the engine would be the right place to implement
> depth-peeling for accurate transparency.  There might be a corresponding
> set of painters, or it might all be self-contained, I don't really know.
>
> The fourth use-case would definitely require separate render engine,
> material, and light nodes specific to the model.  The sky's the limit
> here, since the model would be defined by us, and only limited by what
> we could dream-up for OpenGL.
>
> Assuming that what you're really interested in is use-case 3, I think
> the place to start would be to create a new painter that "understands" a
> RenderMan material and makes some attempt at duplicating it, e.g.
> rendering textures.

Actually it's more use-case 1 I'm talking about, but I think we might
have a bit different ideas about it. Basically what I'm thinking about
here is that although not all "final" render models will have texture
mapping in the classic sense, it's pretty commonly used functionality.
Therefore I think seeing texture placement is very much a part of case
1. I realize I've been a bit unclear though. What I mean with
previewing the shaderman shaders etc isn't really about seeing what
they will look like. What I mean is that very often the texture you
want to use to see your texture placement is one of the textures bound
to a material of the object. You'll want to see live in the viewport
how things line up etc when moving the texture coordinates around. As
I said before the selection of texture could be on the material side
("preview_texture"-way, selectable on the material), but thinking more
about it, maybe it'd be better on some other more "global" level. This
is what I'd like to figure out. :)

/Anders

Re: [K3d-development] Textures, again

[Anders S. <and...@gm...>]

On Sat, Jun 28, 2008 at 4:53 PM, Anders Stenberg
<and...@gm...> wrote:
> On Sat, Jun 28, 2008 at 7:06 AM, Timothy M. Shead <ts...@k-...> wrote:
>> Anders Stenberg wrote:
>>>> http://www.k-3d.org/wiki/Render_Models
>>>> http://www.k-3d.org/wiki/Material_Design
>>>>
>>> While the OpenGL render model is separate from the other render
>>> models, it still has a connection due to it being the editing
>>> renderer. When you manipulate textures or lights or whatever you'll
>>> want a fair preview of what's happening in the viewport. Of course you
>>> can't match the final output in most cases, and (as noted in the
>>> Render_Models page) it's not even really desirable since it might just
>>> add more clutter, but still you'll often want to be able to see some
>>> kind of output. I'm not sure how this info should be communicated. One
>>> way would be to have some property that materials may provide that the
>>> GL painter could understand (e.g. "preview_texture", "preview_color",
>>> etc). Another would be to have some kind of connection between
>>> materials and a OpenGLMaterial, all in a MultiMaterial. Yet another
>>> would be to just have just the current stuff (with a slightly better
>>> OpenGLMaterial) and leave it to the Artist.
>>>
>> I think that there are several distinct OpenGL use-cases:
>>
>> * Rendering for modeling & scene setup.
>> * Rendering for technical illustration, informatics, and scientific
>> visualization.
>> * Rendering previews for offline render-engines.
>> * Rendering high-quality final output using OpenGL.
>>
>> The first use-case is basically there already, in the sense that we
>> provide special capabilities (such as the headlight) that are specific
>> to editing.
>>
>> The second use-case requires more control over the rendered scene, but
>> is intended to provide insight into data rather than simulating "real
>> life".  I've done a couple of projects that feel into this category.  I
>> envision that this is the case where the (currently ignored)
>> OpenGLMaterial and (hypothetical) OpenGLLight nodes would be used.
>>
>> The third use-case is where we would try to reproduce the output of a
>> RenderMan / Yafray / Foo render engine.  For this case I *wouldn't*
>> provide any preview-specific fields in the objects, nor special material
>> or light objects, since the point is to preview the artists' existing
>> choices.  There would probably be a separate render engine in this case
>> - as an example, the engine would be the right place to implement
>> depth-peeling for accurate transparency.  There might be a corresponding
>> set of painters, or it might all be self-contained, I don't really know.
>>
>> The fourth use-case would definitely require separate render engine,
>> material, and light nodes specific to the model.  The sky's the limit
>> here, since the model would be defined by us, and only limited by what
>> we could dream-up for OpenGL.
>>
>> Assuming that what you're really interested in is use-case 3, I think
>> the place to start would be to create a new painter that "understands" a
>> RenderMan material and makes some attempt at duplicating it, e.g.
>> rendering textures.
>
> Actually it's more use-case 1 I'm talking about, but I think we might
> have a bit different ideas about it. Basically what I'm thinking about
> here is that although not all "final" render models will have texture
> mapping in the classic sense, it's pretty commonly used functionality.
> Therefore I think seeing texture placement is very much a part of case
> 1. I realize I've been a bit unclear though. What I mean with
> previewing the shaderman shaders etc isn't really about seeing what
> they will look like. What I mean is that very often the texture you
> want to use to see your texture placement is one of the textures bound
> to a material of the object. You'll want to see live in the viewport
> how things line up etc when moving the texture coordinates around. As
> I said before the selection of texture could be on the material side
> ("preview_texture"-way, selectable on the material), but thinking more
> about it, maybe it'd be better on some other more "global" level. This
> is what I'd like to figure out. :)
>
> /Anders
>

Hmm, thinking one second more about it... :)

Maybe you're right that it's a bit of case 3 I'm thinking about after
all. Or rather, I think I could skew my way of thinking into that. :)
As an example, in Maya there are a bunch of "display modes". The three
main ones are wireframe, shaded, and textured. Often when modelling
and working with the mesh you use either wireframe or shaded, and when
texturing stuff you use the textured view. In Maya all these are
implemented as only one "renderer", but with different options set.
But thinking about it, maybe to do something similar in K-3D it'd be
better to implement it as switching between different painters. I.e.
instead of switching the default painter to a "textured" or "preview"
mode, you switch painter to a "ShaderMan preview" painter or whatever.
It doesn't quite land at case 3 since I'm still primarily thinking
about "preview" in a sense like "provide enough visual cues to know
what the heck you're doing when you work things like textures" :)
This would need to have a quick way of exchanging painters, but that
part is easy of course.

Do I make sense? :)
/Anders

Re: [K3d-development] Textures, again

[Timothy M. S. <ts...@k-...>]

Anders Stenberg wrote:
> On Sat, Jun 28, 2008 at 4:53 PM, Anders Stenberg
> <and...@gm...> wrote:
>   
>> On Sat, Jun 28, 2008 at 7:06 AM, Timothy M. Shead <ts...@k-...> wrote:
>>     
>>> I think that there are several distinct OpenGL use-cases:
>>>
>>> * Rendering for modeling & scene setup.
>>> * Rendering for technical illustration, informatics, and scientific
>>> visualization.
>>> * Rendering previews for offline render-engines.
>>> * Rendering high-quality final output using OpenGL.
>>>       
>
> Hmm, thinking one second more about it... :)
>
> Maybe you're right that it's a bit of case 3 I'm thinking about after
> all. Or rather, I think I could skew my way of thinking into that. :)
> As an example, in Maya there are a bunch of "display modes". The three
> main ones are wireframe, shaded, and textured. Often when modelling
> and working with the mesh you use either wireframe or shaded, and when
> texturing stuff you use the textured view. In Maya all these are
> implemented as only one "renderer", but with different options set.
> But thinking about it, maybe to do something similar in K-3D it'd be
> better to implement it as switching between different painters. I.e.
> instead of switching the default painter to a "textured" or "preview"
> mode, you switch painter to a "ShaderMan preview" painter or whatever.
> It doesn't quite land at case 3 since I'm still primarily thinking
> about "preview" in a sense like "provide enough visual cues to know
> what the heck you're doing when you work things like textures" :)
> This would need to have a quick way of exchanging painters, but that
> part is easy of course.
>   
Yes, this is pretty-much what I had in mind - you might have a "texture 
preview painter" which would provide some sensible default texture for 
uv-mapping purposes, and allow you to override it (this would be a 
property of the painter).  Then you'd have the RenderManPreview painter 
which would encapsulate much-more-sophisticated logic for figuring-out 
what texture (if any) to display.

Cheers,
Tim

-- 
Timothy M. Shead, K-3D founder
http://www.k-3d.org

Re: [K3d-development] Textures, again

[Anders S. <and...@gm...>]

On Sat, Jun 28, 2008 at 9:08 PM, Timothy M. Shead <ts...@k-...> wrote:
> Anders Stenberg wrote:
>> On Sat, Jun 28, 2008 at 4:53 PM, Anders Stenberg
>> <and...@gm...> wrote:
>>
>>> On Sat, Jun 28, 2008 at 7:06 AM, Timothy M. Shead <ts...@k-...> wrote:
>>>
>>>> I think that there are several distinct OpenGL use-cases:
>>>>
>>>> * Rendering for modeling & scene setup.
>>>> * Rendering for technical illustration, informatics, and scientific
>>>> visualization.
>>>> * Rendering previews for offline render-engines.
>>>> * Rendering high-quality final output using OpenGL.
>>>>
>>
>> Hmm, thinking one second more about it... :)
>>
>> Maybe you're right that it's a bit of case 3 I'm thinking about after
>> all. Or rather, I think I could skew my way of thinking into that. :)
>> As an example, in Maya there are a bunch of "display modes". The three
>> main ones are wireframe, shaded, and textured. Often when modelling
>> and working with the mesh you use either wireframe or shaded, and when
>> texturing stuff you use the textured view. In Maya all these are
>> implemented as only one "renderer", but with different options set.
>> But thinking about it, maybe to do something similar in K-3D it'd be
>> better to implement it as switching between different painters. I.e.
>> instead of switching the default painter to a "textured" or "preview"
>> mode, you switch painter to a "ShaderMan preview" painter or whatever.
>> It doesn't quite land at case 3 since I'm still primarily thinking
>> about "preview" in a sense like "provide enough visual cues to know
>> what the heck you're doing when you work things like textures" :)
>> This would need to have a quick way of exchanging painters, but that
>> part is easy of course.
>>
> Yes, this is pretty-much what I had in mind - you might have a "texture
> preview painter" which would provide some sensible default texture for
> uv-mapping purposes, and allow you to override it (this would be a
> property of the painter).  Then you'd have the RenderManPreview painter
> which would encapsulate much-more-sophisticated logic for figuring-out
> what texture (if any) to display.
>
> Cheers,
> Tim
>

Great, then I think we're back on the same page. :)
In my mind, this "sensible default texture" would usually be one of
the textures used by the materials of the objects. Selecting this is
mostly a UI matter I guess (what suggestions to show when selecting a
texture etc), but actually informing the painter what texture to use
is a bit more complex. It's a property on object (or material) level,
but it's highly painter specific. What's the policy on things like
that? Where/how should info that is specific for a "third party"
module but bound to a node be stored?

/Anders

Re: [K3d-development] Textures, again

[Timothy M. S. <ts...@k-...>]

Anders Stenberg wrote:
> In my mind, this "sensible default texture" would usually be one of
> the textures used by the materials of the objects. Selecting this is
> mostly a UI matter I guess (what suggestions to show when selecting a
> texture etc), but actually informing the painter what texture to use
> is a bit more complex. It's a property on object (or material) level,
> but it's highly painter specific. What's the policy on things like
> that? Where/how should info that is specific for a "third party"
> module but bound to a node be stored?
>   
Maybe we aren't on the same page :) ... my proposal was this:

* To get the ball rolling, create a OpenGLTexturedFooPainter.  This 
painter has a "texture" property all its own.  By default, the texture 
is some grid-like thing that is designed to be useful for visualizing 
mappings.  Users can override this with some other texture of their 
choice.  The painter itself is "dumb" - it just renders using its 
internal choice of painter.  Thus, this painter realizes your original 
concept of specifying a "preview" texture in the material, it just puts 
the state somewhere else (the painter).

* Later, create OpenGLRenderManPreviewPainter, which has the logic to 
look at gprim materials, scan through the shaders, and figure-out what 
to display.  There would be painter state to allow the user to influence 
the decision, e.g: I'm using a shader that takes two textures as inputs, 
so I have to choose one-or-the-other.

Cheers,
Tim


-- 
Timothy M. Shead, K-3D founder
http://www.k-3d.org

Re: [K3d-development] Textures, again

[Anders S. <and...@gm...>]

>> In my mind, this "sensible default texture" would usually be one of
>> the textures used by the materials of the objects. Selecting this is
>> mostly a UI matter I guess (what suggestions to show when selecting a
>> texture etc), but actually informing the painter what texture to use
>> is a bit more complex. It's a property on object (or material) level,
>> but it's highly painter specific. What's the policy on things like
>> that? Where/how should info that is specific for a "third party"
>> module but bound to a node be stored?
>>
> Maybe we aren't on the same page :) ... my proposal was this:
>
> * To get the ball rolling, create a OpenGLTexturedFooPainter.  This
> painter has a "texture" property all its own.  By default, the texture
> is some grid-like thing that is designed to be useful for visualizing
> mappings.  Users can override this with some other texture of their
> choice.  The painter itself is "dumb" - it just renders using its
> internal choice of painter.  Thus, this painter realizes your original
> concept of specifying a "preview" texture in the material, it just puts
> the state somewhere else (the painter).
>
> * Later, create OpenGLRenderManPreviewPainter, which has the logic to
> look at gprim materials, scan through the shaders, and figure-out what
> to display.  There would be painter state to allow the user to influence
> the decision, e.g: I'm using a shader that takes two textures as inputs,
> so I have to choose one-or-the-other.


Well, what I want to do is exactly the first here (with
OpenGLTexturedFooPainter), but I think it's pretty important to have
the texture selectable per object, not globally. But sure, I can do
global for now, just to get something running.

/Anders

Re: [K3d-development] Textures, again

[Joaquín D. <hoa...@ya...>]

Anders Stenberg wrote:
>>> In my mind, this "sensible default texture" would usually be one of
>>> the textures used by the materials of the objects. Selecting this is
>>> mostly a UI matter I guess (what suggestions to show when selecting a
>>> texture etc), but actually informing the painter what texture to use
>>> is a bit more complex. It's a property on object (or material) level,
>>> but it's highly painter specific. What's the policy on things like
>>> that? Where/how should info that is specific for a "third party"
>>> module but bound to a node be stored?
>>>
>> Maybe we aren't on the same page :) ... my proposal was this:
>>
>> * To get the ball rolling, create a OpenGLTexturedFooPainter.  This
>> painter has a "texture" property all its own.  By default, the texture
>> is some grid-like thing that is designed to be useful for visualizing
>> mappings.  Users can override this with some other texture of their
>> choice.  The painter itself is "dumb" - it just renders using its
>> internal choice of painter.  Thus, this painter realizes your original
>> concept of specifying a "preview" texture in the material, it just puts
>> the state somewhere else (the painter).
>>
>> * Later, create OpenGLRenderManPreviewPainter, which has the logic to
>> look at gprim materials, scan through the shaders, and figure-out what
>> to display.  There would be painter state to allow the user to influence
>> the decision, e.g: I'm using a shader that takes two textures as inputs,
>> so I have to choose one-or-the-other.
> 
> 
> Well, what I want to do is exactly the first here (with
> OpenGLTexturedFooPainter), but I think it's pretty important to have
> the texture selectable per object, not globally. But sure, I can do
> global for now, just to get something running.
This pitfall is also for any painter. The workaround is defining a new painter 
and assign it to the object. (for example if you want different colors).

Tim:
Will this approach be automated in future? Having one painter for every scene 
object would have sense? (for example every object has a different color)
I guess this is not a overhead on the pipeline, isn't it?

Cheers!
Joaquín

Re: [K3d-development] Textures, again

[Timothy M. S. <ts...@k-...>]

Anders Stenberg wrote:
>> * To get the ball rolling, create a OpenGLTexturedFooPainter.  This
>> painter has a "texture" property all its own.  By default, the texture
>> is some grid-like thing that is designed to be useful for visualizing
>> mappings.  Users can override this with some other texture of their
>> choice.  The painter itself is "dumb" - it just renders using its
>> internal choice of painter.  Thus, this painter realizes your original
>> concept of specifying a "preview" texture in the material, it just puts
>> the state somewhere else (the painter).
>>     
> Well, what I want to do is exactly the first here (with
> OpenGLTexturedFooPainter), but I think it's pretty important to have
> the texture selectable per object, not globally. But sure, I can do
> global for now, just to get something running.
>   
To clarify one point - painters are only used globally as a default - 
they can be assigned on a per-mesh-instance basis currently, and we have 
some preliminary design on assigning them per-render-engine too:

http://www.k-3d.org/wiki/Per_Render_Engine_Painters

The *real* obstacle to working with painters this way is the lack of UI 
for managing them (setting them up manually is painful), but that is a 
solvable problem.

Cheers,
Tim

-- 
Timothy M. Shead, K-3D founder
http://www.k-3d.org

Re: [K3d-development] Textures, again

[Anders S. <and...@gm...>]

On Mon, Jun 30, 2008 at 4:52 AM, Timothy M. Shead <ts...@k-...> wrote:
> Anders Stenberg wrote:
>>> * To get the ball rolling, create a OpenGLTexturedFooPainter.  This
>>> painter has a "texture" property all its own.  By default, the texture
>>> is some grid-like thing that is designed to be useful for visualizing
>>> mappings.  Users can override this with some other texture of their
>>> choice.  The painter itself is "dumb" - it just renders using its
>>> internal choice of painter.  Thus, this painter realizes your original
>>> concept of specifying a "preview" texture in the material, it just puts
>>> the state somewhere else (the painter).
>>>
>> Well, what I want to do is exactly the first here (with
>> OpenGLTexturedFooPainter), but I think it's pretty important to have
>> the texture selectable per object, not globally. But sure, I can do
>> global for now, just to get something running.
>>
> To clarify one point - painters are only used globally as a default -
> they can be assigned on a per-mesh-instance basis currently, and we have
> some preliminary design on assigning them per-render-engine too:
>
> http://www.k-3d.org/wiki/Per_Render_Engine_Painters

Yes, I realize this, and that's why I think there's a bit of a
problem. I'd rather see one painter that reads info from the object
for some small object differences, than each object having its own
painter. Though I also realize that adds a problem since it's not very
nice for a object to have weird properties specific for one painter
plugin.

Anyhoo, I did a quick mockup with a OpenGLTexturedFacePainter that
just has a global texture, and it works pretty fine. It's all a slight
bit hacky so far, but I think I'll commit some stuff soon.

/Anders

>
> The *real* obstacle to working with painters this way is the lack of UI
> for managing them (setting them up manually is painful), but that is a
> solvable problem.

Absolutely, but as you say that's solvable and fairly straight forward.

/Anders