|
»
NURBS patch uniform data
|
View:
New views
14 Messages
—
Rating Filter:
Alert me
|
 |
NURBS patch uniform data
by bART Janssens-2
::
Rate this Message:
Hi,
To further extend the SVG importer material handling, the SVG mesh reader now adds line colors as uniform data to the K-3D nurbs curve. This gets propagated when extrudung the curve. Doing this uncovered a bug: it seems that NURBS uniform data is defined per patch segment, not per patch, as explained in the RenderMan spec (page 73): "RiNuPatch primitive variables are therefore defined to have one uniform value per segment and one varying value per segment corner. The number of uniform primitive variables is therefore nusegments × nvsegments" Currently, our definition of uniform data is per-patch data, so I propose to simply duplicate our uniform values for every segment in the patch. Also, LuxRender currently doesn't use the color arrays. Should they be interpreted as a material "base color", or are they completely RenderMan-specific? Cheers, -- Bart ------------------------------------------------------------------------------ _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: NURBS patch uniform data
by Daniel Scott Matthews
::
Rate this Message:
On Sun, Jul 26, 2009 at 7:23 AM, Bart Janssens<bart.janssens@...> wrote:
> Hi, > > To further extend the SVG importer material handling, the SVG mesh > reader now adds line colors as uniform data to the K-3D nurbs curve. > This gets propagated when extrudung the curve. Doing this uncovered a > bug: it seems that NURBS uniform data is defined per patch segment, > not per patch, as explained in the RenderMan spec (page 73): > "RiNuPatch primitive variables are therefore defined to have one > uniform value per segment and one varying value per segment corner. The number > of uniform primitive variables is therefore nusegments × nvsegments" > > Currently, our definition of uniform data is per-patch data, so I > propose to simply duplicate our uniform values for every segment in > the patch. > > Also, LuxRender currently doesn't use the color arrays. Should they be > interpreted as a material "base color", or are they completely > RenderMan-specific? > Is there some way of using the MultiMaterial node to store imported mesh material data so that it can be connected to by any renderer specific nodes? ------------------------------------------------------------------------------ _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: NURBS patch uniform data
by Timothy M. Shead
::
Rate this Message:
Bart Janssens wrote:
> To further extend the SVG importer material handling, the SVG mesh > reader now adds line colors as uniform data to the K-3D nurbs curve. > This gets propagated when extrudung the curve. Doing this uncovered a > bug: it seems that NURBS uniform data is defined per patch segment, > not per patch, as explained in the RenderMan spec (page 73): > "RiNuPatch primitive variables are therefore defined to have one > uniform value per segment and one varying value per segment corner. The number > of uniform primitive variables is therefore nusegments × nvsegments" Uniform data should be "per patch" ... how does this bug manifest itself? Is it in the SVG importer, the NURBS validation code, the painter, or what? We should just fix whatever's broken. > Also, LuxRender currently doesn't use the color arrays. Should they be > interpreted as a material "base color", or are they completely > RenderMan-specific? Pulling this data into primitive is cool, but without LuxRender support for user attributes, I don't see it getting used in that context; attributes work well with RenderMan because they just show up as variables that you can use in a shader. Cheers, Tim ------------------------------------------------------------------------------ _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: NURBS patch uniform data
by bART Janssens-2
::
Rate this Message:
On Sun, Jul 26, 2009 at 1:33 AM, Timothy M. Shead<tshead@...> wrote:
> Uniform data should be "per patch" ... how does this bug manifest > itself? Is it in the SVG importer, the NURBS validation code, the > painter, or what? We should just fix whatever's broken. It was in the painter, the fix is in http://code.google.com/p/k3d-bart/source/detail?r=8a790e5431cfc5d120750c62ab290b017f4cab40 The result was that only the first segment got rendered correctly. The attached render outputs show the results before and after the patch on a NURBS patch with 3 vertical segments. I agree uniform data should be per patch, but it does not match RenderMan in this case. What if someone wants to define per segment colors? > Pulling this data into primitive is cool, but without LuxRender support > for user attributes, I don't see it getting used in that context; > attributes work well with RenderMan because they just show up as > variables that you can use in a shader. OK, I was just wondering if we should take some of the commonly used data arrays, such as the color array, and apply this in our RenderEngine to manipulate the materials description output to Lux, i.e. in the "Texture "a" "color" "constant" "color value" [1 1 1]" line? Cheers, -- Bart ------------------------------------------------------------------------------ _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: NURBS patch uniform data
by bART Janssens-2
::
Rate this Message:
On Sat, Jul 25, 2009 at 11:27 PM, Daniel Scott
Matthews<dsmatthews@...> wrote: > Is there some way of using the MultiMaterial node to store imported > mesh material data so that it can be connected to by any renderer > specific nodes? With SVG, no material is created by the MeshReader. Or did you have another importer in mind? If materials are created, they can be put into MultiMaterial. Cheers, -- Bart ------------------------------------------------------------------------------ _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
|
|
|
Re: NURBS patch uniform data
by Timothy M. Shead
::
Rate this Message:
Bart Janssens wrote:
> On Sun, Jul 26, 2009 at 1:33 AM, Timothy M. Shead<tshead@...> wrote: >> Uniform data should be "per patch" ... how does this bug manifest >> itself? Is it in the SVG importer, the NURBS validation code, the >> painter, or what? We should just fix whatever's broken. > > It was in the painter, the fix is in > http://code.google.com/p/k3d-bart/source/detail?r=8a790e5431cfc5d120750c62ab290b017f4cab40 > The result was that only the first segment got rendered correctly. The > attached render outputs show the results before and after the patch on > a NURBS patch with 3 vertical segments. > > I agree uniform data should be per patch, but it does not match > RenderMan in this case. What if someone wants to define per segment > colors? Pardon the confusion, I was thinking "RiPatch", not "RiNuPatch" ... from the documentation for the latter: > A NuPatch may be thought of as a nonperiodic uniform B-spline mesh with (1+nu−uorder ) > segments in the u parametric direction, and (1+nv −vorder ) segments in the v para- > metric direction. RiNuPatch primitive variables are therefore defined to have one > uniform value per segment and one varying value per segment corner. The number > of uniform primitive variables is therefore nusegments × nvsegments, and the number > of varying variables is (nusegments+1) × (nvsegments+1). Note that this results in re- > dundant parameter values corresponding to repeated knot values, for instance when > the knot vector indicates the RiNuPatch is in Bezier form. Primitive variables of class > vertex contain nu × nv values of the appropriate type, and are interpolated using > the same methods as the surface position ”P”. Primitive variables that are of class > constant will have a single value for the entire mesh. ... so the original behavior is correct. As a rule of thumb, it has always been my intent that our "original" set of primitives follow RenderMan, so whenever there's any doubt, RenderMan is correct. Cheers, Tim ------------------------------------------------------------------------------ _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: NURBS patch uniform data
by bART Janssens-2
::
Rate this Message:
On Sun, Jul 26, 2009 at 11:42 PM, Timothy M. Shead<tshead@...> wrote:
> ... so the original behavior is correct. As a rule of thumb, it has > always been my intent that our "original" set of primitives follow > RenderMan, so whenever there's any doubt, RenderMan is correct. OK, so that means we have to change the validation rules for nurbs_patch uniform data, then, right? It assumes one value per nurbs patch now. This is actually what constant data is supposed to be, so we should change that too. Likewise, varying data is defined per segment corner, not per patch corner. -- Bart ------------------------------------------------------------------------------ _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: NURBS patch uniform data
by Timothy M. Shead
::
Rate this Message:
Bart Janssens wrote:
> On Sun, Jul 26, 2009 at 11:42 PM, Timothy M. Shead<tshead@...> wrote: >> ... so the original behavior is correct. As a rule of thumb, it has >> always been my intent that our "original" set of primitives follow >> RenderMan, so whenever there's any doubt, RenderMan is correct. > > OK, so that means we have to change the validation rules for > nurbs_patch uniform data, then, right? It assumes one value per nurbs > patch now. This is actually what constant data is supposed to be, so > we should change that too. Likewise, varying data is defined per > segment corner, not per patch corner. > Yep, I'm looking at this right now ... since this goes with the rest of the changes in the k3d-tables repo, better that I fix it there. Cheers, Tim ------------------------------------------------------------------------------ _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: NURBS patch uniform data
by Timothy M. Shead
::
Rate this Message:
Timothy M. Shead wrote:
> Bart Janssens wrote: >> On Sun, Jul 26, 2009 at 11:42 PM, Timothy M. Shead<tshead@...> wrote: >>> ... so the original behavior is correct. As a rule of thumb, it has >>> always been my intent that our "original" set of primitives follow >>> RenderMan, so whenever there's any doubt, RenderMan is correct. >> OK, so that means we have to change the validation rules for >> nurbs_patch uniform data, then, right? It assumes one value per nurbs >> patch now. This is actually what constant data is supposed to be, so >> we should change that too. Likewise, varying data is defined per >> segment corner, not per patch corner. Following-up, I've added an auto-generated page to the wiki to summarize the components in our current generic primitives: http://k-3d.org/wiki/Primitive_Components ... from the table, you will see that there is a fair amount of consistency, and you can infer interesting things from what's there. For example: primitives that don't use points (such as quadrics) have no vertex attributes. Our lightweight primitives (point groups and curves) have constant structure, because they specify materials on a global (rather than per-point or per-curve) basis. You can also see the oddballs that need to change - for example, NURBS patches and polyhedra are using constant structure in a weird way, which I'm going to change. An interesting effect of interpreting NURBS patch segments as uniform is that selecting a NURBS patch is no-longer a uniform selection - it's something else, which I haven't put a name to. Cheers, Tim ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: NURBS patch uniform data
by bART Janssens-2
::
Rate this Message:
On Thu, Jul 30, 2009 at 7:50 AM, Timothy M. Shead<tshead@...> wrote:
> An interesting effect of interpreting NURBS patch segments as uniform is > that selecting a NURBS patch is no-longer a uniform selection - it's > something else, which I haven't put a name to. For NURBS, the RenderMan spec explicitely states this is constant data. They state: "Primitive variables that are of class constant will have a single value for the entire mesh." But in the first phrase of the paragraph, "mesh" is defined as being a single NURBS patch in this context: "A NuPatch may be thought of as a nonperiodic uniform B-spline mesh with (1+nu-uorder ) segments in the u parametric direction, and (1+nv -vorder ) segments in the v para- metric direction." So we just need selection for constant data. For NURBS this would be patches, for polyhedra it would be shells. Cheers, -- Bart ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: NURBS patch uniform data
by Timothy M. Shead
::
Rate this Message:
Bart Janssens wrote:
> On Thu, Jul 30, 2009 at 7:50 AM, Timothy M. Shead<tshead@...> wrote: >> An interesting effect of interpreting NURBS patch segments as uniform is >> that selecting a NURBS patch is no-longer a uniform selection - it's >> something else, which I haven't put a name to. > > For NURBS, the RenderMan spec explicitely states this is constant > data. They state: > > "Primitive variables that are of class > constant will have a single value for the entire mesh." > > But in the first phrase of the paragraph, "mesh" is defined as being a > single NURBS patch in this context: > > "A NuPatch may be thought of as a nonperiodic uniform B-spline mesh > with (1+nu-uorder ) > segments in the u parametric direction, and (1+nv -vorder ) segments > in the v para- > metric direction." > > So we just need selection for constant data. For NURBS this would be > patches, for polyhedra it would be shells. > > Cheers, > I have to admit, having all of the primitives & components in front of me makes the way forward less clear. On some level, you could argue "what's in a name?", since the set of arrays in a primitive aren't changing, just the names for the components that they live in. However, it does have a pretty big impact on selection: when you choose a selection type on the main toolbar, you are basically choosing the component. Having one button for "curves, bilinear patches, bicubic patches, and polygon faces", and another button just for "NURBS patches" seems wildly suboptimal. So I'm leaning towards your original suggestion of redefining "uniform" to mean what *we* want it to mean, and just accepting the fact that the RenderMan painters have to do some totally trivial mapping from our component types to RenderMan types. Cheers, Tim ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: NURBS patch uniform data
by bART Janssens-2
::
Rate this Message:
On Fri, Jul 31, 2009 at 7:39 AM, Timothy M. Shead<tshead@...> wrote:
> I have to admit, having all of the primitives & components in front of > me makes the way forward less clear. On some level, you could argue > "what's in a name?", since the set of arrays in a primitive aren't > changing, just the names for the components that they live in. However, > it does have a pretty big impact on selection: when you choose a > selection type on the main toolbar, you are basically choosing the > component. Having one button for "curves, bilinear patches, bicubic > patches, and polygon faces", and another button just for "NURBS patches" > seems wildly suboptimal. So I'm leaning towards your original Maybe the root of the problem is that we are using the RenderMan definitions of data that is meant for material handling for our selections. For me, having a selection button that selects both NURBS patches and curves is illogical. Perhaps we should review how the selection arrays are defined, and support 3 basic selection types: - points - lines - faces In case of a NURBS curve, there would be no faces array. For both polyhedra and NURBS patches, the faces array would refer to faces and patches, respectively. In the future, we will probably need additional "advanced" selection modes: - face corners (i.e. to select topology associated with varying data) - line segments (to manipulate parts of NURBS curve, i.e. something like split curve) - patch segments (NURBS patch manipulation: allow extruding a segment, associate a color with it, ...) I don't know if these should be explicit arrays in the mesh, however. > suggestion of redefining "uniform" to mean what *we* want it to mean, > and just accepting the fact that the RenderMan painters have to do some > totally trivial mapping from our component types to RenderMan types. Well, I've changed my mind about that :) It's probably best if we stick to RenderMan for the actual data arrays. Changing the behavior of uniform means almost certainly that some shaders will no longer produce the expected results if there is no way to create a uniform array in the war RenderMan expects it. Think i.e. a checkerboard pattern on a single NURBS patch. Cheers, -- Bart ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Primitive Components [was:] NURBS patch uniform data
by Timothy M. Shead
::
Rate this Message:
Bart:
Not necessarily disagreeing with any of your points, but this is a tough topic to discuss because there are so many overlapping issues, and the vocabulary hasn't firmed-up yet. So I will apologize in advance and try to walk though some context, this is as much about firming-up my own mental model as anything else ... * All of the generic primitives are made-up of "components", where a component is a collection of arrays that are all the same length. * The set of components in a primitive will vary, based on the primitive type. A "foo" component stores "per-foo" data, where "foo" is some aspect of the primitive. This is pretty intuitive: a patch primitive has a component that stores per-patch data, a polyhedron primitive has components to store per-face and per-edge data, etc. * The set of arrays in a component will vary, based on the primitive type. Where an array is located says a lot about its function: if the "foo" component has a selection array, it means that users can make "per-foo" component selections. If the "foo" component has a material array, it means materials can be assigned on a "per-foo" basis. * Many array types could exist in multiple components: a primitive might have selection arrays in multiple components, allowing multiple types of selection (such as per-face and per-edge). An attribute might be defined on multiple components, such as per-vertex and face-varying normals. * Note that interactive selection is intimately coupled to components: a selection is fundamentally a set of selection-state changes, applied to a specific selection array in a specific component. The list of available component names dictates the list of available selection types. * In-general, the designer of a new primitive type has carte blanche to use as many component types as they want, and call them whatever they want. * However, there are a couple of incentives not to run too wild: the code that does OpenGL selection can only distinguish selection records based on integers, implying an enumeration of "available interactive selection types." Similarly, the UI has to present users with some reasonably fixed list of selection (component) types. So the trick is to define the "right" set of components. One guiding principle comes to mind: * Specific component types should have reasonably consistent meanings across primitives, e.g. "constant" should always have length one (as it already does for 17 out-of 18 primitive types. "vertex" should always mean "the number of vertices used by the primitive", etc. Cheers, Tim ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
bug.jpg (4K) 
| Free embeddable forum powered by Nabble | Forum Help |
