In article <3fe4f632$1@news.povray.org>,
 "Tim Nikias v2.0" <tim.nikias (@) nolights.de> wrote:

> What I've read on these groups so far seems to suggest that POV-Ray 4 will
> be more flexible on the "modding" side, for example stuff like *real*
> plug-ins, not just include-files.

This seems to be an oddly persistent misconception...almost as bad as 
the "4.0 will be GPL" one. POV-Ray does not support plugins because 
there is no platform-independent way of loading them, and the plugins 
themselves would be platform dependent, making for a support nightmare. 
This will not change when POV 4.0 is released. It would be possible to 
load platform-independent bytecode files like Java does, but there's no 
real reason to do so...you might as well just generate the bytecodes 
from source, and loading precompiled bytecode would not add any 
capability. It would be slightly faster, but source compiling won't be a 
speed bottleneck like scene parsing currently is...and even now, only 
include files that do heavy processing cause any slowdown.


> The new number shows that it'll be a complete rewrite,

Because of it being a rewrite, it merits a full version increase. A full 
version number increase does not indicate that it's a rewrite, however, 
only that it's a major update.


> and if I recall correctly, there were numerous times when
> someone mentioned that the new texturing model in 4 might be completely
> different from what we have today, to make room for a much more flexible
> texturing.

Any redesign and rewrite of the code will make it far easier to add this 
sort of thing.


> Making POV-Ray faster might be nice, though I don't really know
> how that could be achieved. To me, it seems like the way things are done
> right now are as efficient as they can get with this model (bounding boxes,
> vista buffers, light buffers, etc), and I don't really expect a speed-up,
> though maybe certain aspect might be made faster (media, isosurfaces, but I
> don't know what I'm talking about here, I just know that they're slow most
> of the time :-).

There are some changes that can be made. Better bounding systems, 
cleaning up of some of the current hacks...multi-processor systems are 
becoming more common, support for multi-thread rendering would give a 
big speedup on those machines.


> As far as
> I'm concerned: as long as POV-Ray is as stable as it is now, I can't
> complain. Some guru will come along and add the next feature I need. :-)

How does an update to the proximity pattern sound? A blur pattern? Or 
how about an extension to functions which lets you get the surface 
normal and ray direction in pattern functions?

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Here is just an example of POVRay being used in the real world to produce
Graphic Design. I got a project where a small company needed illustrations
of a prototype but in final production stage. The final design of the
product was not fully decided. This meant I would build one illustration and
present it. After evaluation of the model I would receive a list of changed.
Like whether the threaded lid should go on the outside or if it should go on
the inside of the body of the product. There was a group of drain spicket's
that got moved from on end of the product to the other and back again. With
all of these changes and renders building this model in any other program
would require major rebuilds for each change. But with POVRay to move the
spicket's I just change one variable and rerender. This is the very power of
the SDL. Changes could be made with out rebuilding the whole model over for
each change.



It sounds to me from reading this thread and my own experience that it is
not really the render engine that makes POVRay so powerful. It is the SDL.
Those that are embedded in the shader method of texturing clash with
POVRay's method. Yes the SDL could be updated to add more control over the
textures but one could still do anything in POVRay now that is done in any
other program. It just takes learning and spending time coding. Perhaps
someone could write another engine that used the SDL but in a different way.
Just like all those renderman compliant renderers. The POV SDL is a
standard.



And on a side note there is not IIRC a rendering engine that renders NURBS
directly. They are always IIRC converted to polygons before rendering. So to
convert NURBS and out put to POVRay is not a handicap for POVRay. In fact
POVRay handles triangles from NURBS better than most rendering engines.



Now a question of my own. Smooth_triangles and 3 norms. Do other programs
use Norms at the vertex or is POVRay unique in this aspect. Lightwave seems
to calculate based on a center norm. I have seen where Lightwave fails and
POVRay triumphs because of this difference.



"Greg M. Johnson" <gregj;-)565### [at] aolcom> wrote in message
news:3fe3c4b0@news.povray.org...
> Gilles said in the other thread that povray was not suitable for the
> production workflow of a movie studio.
>
> I guess I don't understand.  Couldn't you simply code-up a situation that
> would be suitable?  For example, in my animations right now, I have
separate
> include files for each character's motion, texturing, and physical
> construction.   Couldn't I hire two character animators to work on the
> movement of each character in a scene,  a 3D'er to do the texturing of
> costumes, and a modeller to build each character,  another to work on the
> set and its lighting.   At the end of every day, I collect the latest
draft
> of the *.INC files they've been assigned to work on, and do a 320x240
render
> overnight.   On weekends, I might do a fullscreen render.    That's sort
of
> how I do it now, 'cept there's one employee working on non-cash contests.
>
>

Post a reply to this message

Wasn't it Another Micheal (Mike) Williams who wrote:

>Now a question of my own. Smooth_triangles and 3 norms. Do other programs
>use Norms at the vertex or is POVRay unique in this aspect. Lightwave seems
>to calculate based on a center norm. I have seen where Lightwave fails and
>POVRay triumphs because of this difference.

I notice that the OBJ file format associates normals with vertices, so
any program that uses OBJ files, or any format that's interconvertible
with OBJ format, would have normals at the vertices.

I don't see how centre normals could work. Surely the normals at the
centres of the triangles of an icosahedron are exactly the same as the
normals of a sphere based on the same triangles.

-- 
Mike Williams
(A different one)

Post a reply to this message

in news:3fe51ea3$1@news.povray.org Micheal (Mike) Williams wrote:

> And on a side note there is not IIRC a rendering engine that renders
> NURBS directly.

Not a complete one but:

The paper
http://www.cs.utah.edu/vissim/papers/raynurbs/raynurbs.html

The code
http://www.acm.org/jgt/papers/MartinCohenFishShirley00/


Ingo

Post a reply to this message

> This seems to be an oddly persistent misconception...almost as bad as
> the "4.0 will be GPL" one. POV-Ray does not support plugins because
> there is no platform-independent way of loading them, and the plugins
> themselves would be platform dependent, making for a support nightmare.

Hm, okay. I remember someone saying something along the lines of making it
easier for the Standard-User to make some changes with POV-Ray's way of
doing things, and I immediately thought of plug-ins. Now that you mention
the "charges" against plug-ins, I can see my mistake: I always forget about
the portability problem.

> Because of it being a rewrite, it merits a full version increase. A full
> version number increase does not indicate that it's a rewrite, however,
> only that it's a major update.

I've learned at the university that you begin with 0.x until you've got the
first stable release, that'll be 1.0 then. Patches and updates to that go
along with 1.0.x and 1.x.x. If the main core of the system is exchanged with
a compete rewrite from scratch, that's when 2.x.x comes into play. But it's
a little hazy to remember, was a few years ago. Thorsten posted a link once
which explained the version-number-system POV-Ray uses. Do you have it?

> How does an update to the proximity pattern sound? A blur pattern? Or
> how about an extension to functions which lets you get the surface
> normal and ray direction in pattern functions?

That all sounds really nice. How about a ray which will output the same
color as it would when being rendered? Sort of like an inbuilt camera? If it
shoots rays at the surface where there's supposed to be the camera-pigment
itself, it could just return black, or some other texture (and black is just
default).
But my point was: several enhancements are nice, but I'm only in the
position of making suggestions. I can't code that good myself (yet, perhaps)
and I can't tell anyone what to do on a project like this. I'm grateful for
every little feature which I can use and rely on, but if, for example, the
proximity-pattern wouldn't be implemented in the first release, I wouldn't
blame anyone. Someone would surely cook some method, be it a patch or
SDL-Code, which can do it, although slower than when it had been implemented
right off the start... Or I would go out and code some little SDL myself and
experiment until I got what I needed (as I do these days on things that I
know I'm capable of...).

Regards,
Tim

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de

Post a reply to this message

news:3fe51ea3$1@news.povray.org...
> all of these changes and renders building this model in any other program
> would require major rebuilds for each change. But with POVRay to move the
> spicket's I just change one variable and rerender. This is the very power
of
> the SDL. Changes could be made with out rebuilding the whole model over
for
> each change.

The possibility to parametrize an object is certainly a big strength of the
SDL. Two things, however:
1) it's reserved for what you can code by yourself with the SDL only, i.e.
without an external modeller. As, we know, this is a lot and some projects
certainly can be done like this (I also know of an entire, real-life,
architectural project coded in SDL rather than with 3D Studio). But it's
also limited, if only by the amount of time you can dedicate to it.

2) let's not assume that this isn't possible in other software. Actually, in
the one I'm learning now, the user has access to the model geometry and can
parametrize them if necessary, make calculations etc.

> They are always IIRC converted to polygons before rendering. So to
> convert NURBS and out put to POVRay is not a handicap for POVRay.
> In fact POVRay handles triangles from NURBS better than most rendering
engines.

As a Rhino user I can tell that having to convert NURBS into POV-Ray is a
handicap. One has to go through the entire model and fine-tune each part so
that the whole thing doesn't end up in a 500 Mb mesh. UV mapping is often
lost in the process, so it's necessary to remap the parts. And of course, a
downsized polygonal mesh is less nice-looking than a native NURBS (or any
other parametric surface in fact).

> And on a side note there is not IIRC a rendering engine that renders NURBS
> directly.

Not all of them certainly, but some do:
Mental Ray
http://www.mentalimages.com/2_1_1_technical/index.html
Renderman
https://renderman.pixar.com/products/tools/renderman.html
Mantra
http://www.sidefx.com/products/houdini/mantra/

Of course, how it's done internally is another problem, but the idea is
still that you feed the renderer a parametric object and that it renders
something nice and smooth and not a bunch of polys.

In any case, NURBS was just an example among others and I'm not specifically
advocating NURBS support in POV-Ray. See the FBX interchange file format,
which gives an idea of what is expected in terms of compatibility :
http://www.kaydara.com/products/fbx/index.php?filename=techspecs


G.

Post a reply to this message

In article <3fe58034@news.povray.org>,
 "Tim Nikias v2.0" <tim.nikias (@) nolights.de> wrote:

> I've learned at the university that you begin with 0.x until you've got the
> first stable release, that'll be 1.0 then. Patches and updates to that go
> along with 1.0.x and 1.x.x. If the main core of the system is exchanged with
> a compete rewrite from scratch, that's when 2.x.x comes into play. But it's
> a little hazy to remember, was a few years ago. Thorsten posted a link once
> which explained the version-number-system POV-Ray uses. Do you have it?

I don't have a reference to what Thorsten posted. However, #.#.X updates 
are bug fixes, #.X updates are minor updates with new features but no 
major changes, and X.0 updates are major updates with large additions or 
changes. A bug fix or minor update will rarely affect backwards 
compatibility, a major update is more likely to do so. A total rewrite 
is a major update, but not all major updates involve total rewrites.


> That all sounds really nice. How about a ray which will output the same
> color as it would when being rendered? Sort of like an inbuilt camera? If it
> shoots rays at the surface where there's supposed to be the camera-pigment
> itself, it could just return black, or some other texture (and black is just
> default).

It is not possible to trace a ray in the scene until after parsing is 
done. Aside from the fact that once you added something to the scene 
based on the results, you will have potentially changed those results, 
it would require doing things like radiosity, photon mapping, and other 
post-parse, pre-render steps, every time you used this feature.


> But my point was: several enhancements are nice, but I'm only in the
> position of making suggestions. I can't code that good myself (yet, perhaps)
> and I can't tell anyone what to do on a project like this. I'm grateful for
> every little feature which I can use and rely on, but if, for example, the
> proximity-pattern wouldn't be implemented in the first release, I wouldn't
> blame anyone.

Hmm, just thought I should clarify something: I don't even know if my 
updated proximity pattern or other patches will make it into the next 
MegaPOV, let alone the official POV 4.0.
BTW, I just finished another pattern: voronoi. It is basically a version 
of the crackle pattern that allows you to specify the points used to 
generate the pattern. It allows some nice effects...I'll post some 
images later, but transferring them from my development machine will be 
a pain. (Long story short: I usually have them linked by ethernet, but I 
don't have an ethernet cable.)

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

>
>As a Rhino user I can tell that having to convert NURBS into POV-Ray is a
>handicap. One has to go through the entire model and fine-tune each part so
>that the whole thing doesn't end up in a 500 Mb mesh. UV mapping is often
>lost in the process, so it's necessary to remap the parts. And of course, a
>downsized polygonal mesh is less nice-looking than a native NURBS (or any
>other parametric surface in fact).
>

I am wondering, whether NURBS support is anywhere on the POV-team's current
agenda.  I've seen such a feature request come up before, and it seems like
such a generally useful modelling integration feature that I am surprised
that nobody has attacked it before.  From the posting by ingo, it does not
seem like it would be rocket science either.  I am asking because I am
considering this as an possible project (once I finish my current one, that
is :)

POV-Ray nurbs support with on-the-fly tessellation / cacheing... that would
be nice...

Andrew

Post a reply to this message

"Gilles Tran" <gitran_nospam_@wanadoo.fr> wrote in message
news:3fe5811d@news.povray.org...
>

> news:3fe51ea3$1@news.povray.org...
> > all of these changes and renders building this model in any other
program
> > would require major rebuilds for each change. But with POVRay to move
the
> > spicket's I just change one variable and rerender. This is the very
power
> of
> > the SDL. Changes could be made with out rebuilding the whole model over
> for
> > each change.
>
> The possibility to parametrize an object is certainly a big strength of
the
> SDL. Two things, however:
> 1) it's reserved for what you can code by yourself with the SDL only, i.e.
> without an external modeller. As, we know, this is a lot and some projects
> certainly can be done like this (I also know of an entire, real-life,
> architectural project coded in SDL rather than with 3D Studio). But it's
> also limited, if only by the amount of time you can dedicate to it.
>
> 2) let's not assume that this isn't possible in other software. Actually,
in
> the one I'm learning now, the user has access to the model geometry and
can
> parametrize them if necessary, make calculations etc.
>
> > They are always IIRC converted to polygons before rendering. So to
> > convert NURBS and out put to POVRay is not a handicap for POVRay.
> > In fact POVRay handles triangles from NURBS better than most rendering
> engines.
>
> As a Rhino user I can tell that having to convert NURBS into POV-Ray is a
> handicap. One has to go through the entire model and fine-tune each part
so
> that the whole thing doesn't end up in a 500 Mb mesh. UV mapping is often
> lost in the process, so it's necessary to remap the parts. And of course,
a
> downsized polygonal mesh is less nice-looking than a native NURBS (or any
> other parametric surface in fact).
>
> > And on a side note there is not IIRC a rendering engine that renders
NURBS
> > directly.
>
> Not all of them certainly, but some do:
> Mental Ray
> http://www.mentalimages.com/2_1_1_technical/index.html
> Renderman
> https://renderman.pixar.com/products/tools/renderman.html
> Mantra
> http://www.sidefx.com/products/houdini/mantra/
>
> Of course, how it's done internally is another problem, but the idea is
> still that you feed the renderer a parametric object and that it renders
> something nice and smooth and not a bunch of polys.

All three rendering systems you mentions (Mentalray, PRman, Mantra) use
tessellation to map polygons onto the surface of a nurbs just before
rendering. They actually render the poly's not the nurbs. So 500M of poly's
is still 500M of poly's regardless of when they are created. In fact it
would seem faster to have already processesed the NURBS to creat the 500M of
poly's before render time so this is not done every time a frame is
rendered. Is not speed the real issue.


>
> In any case, NURBS was just an example among others and I'm not
specifically
> advocating NURBS support in POV-Ray. See the FBX interchange file format,
> which gives an idea of what is expected in terms of compatibility :
> http://www.kaydara.com/products/fbx/index.php?filename=techspecs
>
NURBS could be written as a macro. In fact I think someone has been working
on that already. Same with subdivisions.

Post a reply to this message

"Mike Williams" <nos### [at] econymdemoncouk> wrote in message
news:2sWFHEA$bS5$EwIK@econym.demon.co.uk...
> Wasn't it Another Micheal (Mike) Williams who wrote:
>
> >Now a question of my own. Smooth_triangles and 3 norms. Do other programs
> >use Norms at the vertex or is POVRay unique in this aspect. Lightwave
seems
> >to calculate based on a center norm. I have seen where Lightwave fails
and
> >POVRay triumphs because of this difference.
>
> I notice that the OBJ file format associates normals with vertices, so
> any program that uses OBJ files, or any format that's interconvertible
> with OBJ format, would have normals at the vertices.
>
> I don't see how centre normals could work. Surely the normals at the
> centres of the triangles of an icosahedron are exactly the same as the
> normals of a sphere based on the same triangles.

I was not sure how it would work either but I can tell you there is a
differance and that Lightwave shows the Norms as being in the center of the
Poly. If there a lot of long nerrow triangles lightwave will mess up the
smoothing. POVRay gets them perfect. I was only guessing at the idea that it
must be the difference in how each handles Norms.

>
> -- 
> Mike Williams
> (A different one)
It has always amazed me how many "Mike Williams" there are in the world.
Sure makes it hard to feel unique.

Post a reply to this message