RE: [Jrman-devel] What we still have to do

[Gerardo H. <ma...@pr...>]

You are right, both motion blur and depth of field are based on
stochastic sampling.
For motion blur we only need to add a sampling time for each sample and
create a new
type of micropolygon that takes into account this sample time and its
own motion.
On the other hand, I still don't have a clear model on how to implement
the spatial
sampling for depth of field.

I am in favor of reorganizing the CVS and doing more work for the GUI
front end. It is
just that in my mind I tend to think in terms of what are the features
we still need to
implement to support the full Renderman spec, and I forget other
important stuf....
For instance, the GUI work you are doing is not part of the Renderman
spec but I believe
it is very important as it makes jrMan easier to use, especially for
novice users.

Other things we probably should be working on are:

1. A jrMan user/reference manual
2. A tutorial introduction to Renderman/jrMan
3. Improve the www.jrman.org web site
4. Other tools:
a) Compositing a set of images into a single image (useful when you have
to use
crop windows to render a complex image in multiple rendering passes)
b) A tool to obtain the bounding box of all the geometry in a rib file
(useful once
we implement DelayedReadArchive)
c) A tool to help in generating ribs for floor reflections, shadow maps,
and environment
maps
d) A tool to help in applying s and t coordinates to geometry, for
texture mapping.

-----Original Message-----
From: jrm...@li...
[mailto:jrm...@li...] On Behalf Of Alessandro
Falappa
Sent: Tuesday, February 03, 2004 4:34 AM
To: jrm...@li...
Subject: Re: [Jrman-devel] What we still have to do


Gerardo Horvilleur wrote:
> There are still many features we need to implement. Here is a list 
> with comments on what has to be done (it's probably incomplete as I am

> doing it from
> memory):
>
> 1. Shading language
> This is probably the most important missing feature. It is one of the 
> most "famous" Renderman features, and many users won't be interested 
> in jrMan until we have it.
>
> 2. Motion blur
> Also very important.
>
> 3. Depth of field
> We should implement it someday but I don't think it is something we 
> need to work on right now.

I believe these two are interrelated, to my knowledge they are an
application of stochastic sampling in the time domain (motion blur) and
in the spatial domain (depth of field). is it right?

> 4. Reflection/Environment mapping
> Once we have this we are finished with implementing all the Renderman 
> mapping features.
>
> 5. Missing primitives
> a) Bicubic patches with basis != Bezier
> This seems quite easy to implement. We should already have done it.
>
> b) PatchMesh
> This also seems quite easy and should already have been done.
>
> c) Curves
> Doesn't seem hard to do. Let's do it as soon as possible.
>
> d) Trimmed NURBS
> These are slightly harder to implement than bicubic patches, but it 
> shouldn't take us more than a few days to have at least a first 
> implementation. These are very important
> because many modelers are NURBS based.
>
> e) Subdivision surfaces
> The same comments as above. Not too hard to implement and they are 
> important.

I'm more fascinated by SDS than NURBS but I agree that NURBS are more
diffuse and well understood.

> f) General polygons
> These are really a pain to implement and I don't know if any one 
> really uses them...
>
> 6. Other features
> a) Implementing a Renderman API to use jrMan directly from a Java 
> program that generates the scene.
> This would be really nice to have. It implies a refactoring to remove
> extract much
> of that functionality from the Parser class. This would also help in
> implementing
> other features like DelayedReadArchive which is really important for
> rendering
> complex scenes.

And this would make it easier as well to build GUI front ends (from
simple ones like what I'm coding to complex modelers).

> b) Level of detail
> Shouldn't be to difficult to implement. I really don't know if many 
> people use this feature.
>
> c) Surface orientation
> Shouldn't be too difficult.
>
> d) Smooth micropolygon shading
> Should be quite easy.
>
> e) Correct interpolation for all parameter types.
> Right now jrMan has a hardcoded implementation for the most common 
> cases. We should reorganize this code to make it easier to generalize.

> I have some ideas on how to
> accomplish this that I will mention on a future email.
>
> f) Constructive solid geometry.
> Doesn't seem to hard but I doesn't seem trivial either. It is 
> something I would like to have, but I am not sure if it's a feature 
> many people need.
>
> g) Procedural primitives
> It will also need the Renderan API mentioned in (a)

From what you say in your post I deduce that you are not in favor of the
CVS reorganization (at least not now) and external "bell and whistles"
but rather you prefer to let the software mature a bit, right?

--
Alessandro Falappa



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration See the
breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Jrman-devel mailing list
Jrm...@li...
https://lists.sourceforge.net/lists/listinfo/jrman-devel