I have been going through all of the messages on the newsgroup as I 
have just subscribed to them this passed day.  As I look I see many 
different ideas and expansions of POV that need to be made or that 
people would like made.  As I go through I am compiling a list of 
grievances and wants and I am going to post it now and ask that if such 
an option has already been added whether by a patch or by another 
program then please let me know before I expend undue effort on the 
creation of such an option.

    First of all I notice the need for some sort of distributed NetPOV.  
I have many ideas for this and I plan on creating a renderer based on 
the DOS version of POV-Ray that does nothing other than render files 
with no GUI or any other apparent interface.  It will have support for 
multiple frames or for rendering a portion of an image...  Output will 
be to file, network stream, internet stream, or any other means I deem 
necessary and useful.

    Secondly I find a need for a multithreaded version of the Windows 
Executables.  This is so easily done that I almost cry myself to sleep 
at night wondering why it wasn't implemented from the beginning.  There 
will be several options that can be set to determine exactly how many 
threads and how you are going to use those threads...  Options will be a 
-Threads option for declaring a number of threads (more threads would 
even speed rendering on a single processor machine) and specifying 
whether those threads would work on an image or part of an image 
-ThreadPart = 1 -ThreadPart = 2....  That way you could render 
multiple frames at a time or quickly render a single image.

    Thirdly an enhancement to the editor is wanted...  You guys say that 
the editor is not able to be written to?  Well a little bit of 
subclassing of the edit control associated with the editor window might 
do you good.  But that is not my main goal in the editor department.  I 
plan on expanding my DevStudio Add-In to use more of the features of POV 
and I plan on doing my editing from within this environment due to it's 
syntax coloring and advanced help features.  Not to mention 
auto-completion which will be added in DevStudio 98/99 whenever it is 
available such as it works in Visual Basic 5.0 now.

    Fourthly I hear everyone complaining about more features and more 
powerful commands in POV...  Well I plan on expanding POV-Ray to make 
use of all of the lexical conventions of several different languages...  
So look forward to POV-Base, POV-Java, and you better believe there will 
be a POV-CPP.  This comes when I think the language could benefit from 
the use of Classes, Multiple Inheritance and Polymorphism.  And some of 
the newer Ray-Tracers might find the ease of use of Basic to be a 
comfort...  Not to mention with the additon of a couple of Java classes 
Java itself could be extended to do some rudimentary Ray-Tracing from a 
simple POV-Java file.  These lexical modifiers would be in the form of 
plugins and source files would carry different extensions to denote 
their different - .PCPP, .PJAVA, and .PBASIC.  A couple of other 
languages may be accounted for as well.  Depending on how much response 
I get to this posting and what everyone else wants.

    Well guys.  I hope to hear from you all soon.  Reply to the group, 
reply to my email, I look forward to hearing from you all.

-- 
_____________________________________
Justin Rogers, CEO DigiTec Web Consultants
Personal Programmer and Web Consultant
Email:  dig### [at] 3nnet

Post a reply to this message

Attachments:
Download 'iso-8859-1' (5 KB)

Please fix your newsreader to not use quoted-printable for posting.  Then
turn off that stupid HTML crap and the vCard crap.  This is Usenet, not the
web.  Thanks.

On Wed, 8 Jul 1998 05:02:48 -0400, Justin Rogers <dig### [at] 3nnet> wrote:
>    First of all I notice the need for some sort of distributed NetPOV.  =
>I have many ideas for this and I plan on creating a renderer based on =
>the DOS version of POV-Ray that does nothing other than render files =
>with no GUI or any other apparent interface.  It will have support for =
>multiple frames or for rendering a portion of an image...  Output will =
>be to file, network stream, internet stream, or any other means I deem =
>necessary and useful.

You'd do better to start with the Unix source.  This idea has been done to
death, and even the POV Team has plans to implement it in version 4. 
Before you spend too much time on this, you might want to look at some of
the available implementations and see if they already do what you're
trying to do.

>    Secondly I find a need for a multithreaded version of the Windows =
>Executables.  This is so easily done that I almost cry myself to sleep =
>at night wondering why it wasn't implemented from the beginning.  There =

If you think it's easy to do, then you haven't tried to do it yet.  Let me
save you some trouble: POV uses a lot of global variables, and they all get
changed in strange ways at strange times.  If you lock them with critical 
sections, only one thread will be running most of the time anyway.  If you 
don't, you'll corrupt the frame quite quickly.  If you make them all 
thread-local, you'll still be working on it when POV4.0 comes out.

I have some code I wrote for my motion-blur patch that would help with 
multithreading, because it moves most of the globals into the frame structure
where they belong, but even I don't have the hubris to believe that 
multithreading would be "easy."

>will be several options that can be set to determine exactly how many =
>threads and how you are going to use those threads...  Options will be a =
>-Threads option for declaring a number of threads (more threads would =
>even speed rendering on a single processor machine) and specifying =

Nonsense.  Thread switching is a very processor-intensive operation.  That
processor time could be better used doing rendering.  If you run more than
one rendering thread on a single-processor machine, I can guarantee it'll be
slower overall.  It would only be faster on IO-bound processes, and rendering
isn't one.

>    Thirdly an enhancement to the editor is wanted...  You guys say that =
>the editor is not able to be written to?  Well a little bit of =
>subclassing of the edit control associated with the editor window might =
>do you good.  

Uh-huh.  Sure.  Whatever.  Look, we're not morons, okay?  Subclassing would
be at best a kludge.  Among other things, it wouldn't set the variable that
POV checks to know when a file has changed.  No, thanks, we'll do it the 
right way if we do it at all.

>But that is not my main goal in the editor department.  I =
>plan on expanding my DevStudio Add-In to use more of the features of POV =
>and I plan on doing my editing from within this environment due to it's =
>syntax coloring and advanced help features.  Not to mention =
>auto-completion which will be added in DevStudio 98/99 whenever it is =
>available such as it works in Visual Basic 5.0 now.

This would actually be nice.  I wouldn't mind having that myself.  Can it 
shell out to POV as well?

>    Fourthly I hear everyone complaining about more features and more =
>powerful commands in POV...  Well I plan on expanding POV-Ray to make =
>use of all of the lexical conventions of several different languages...  =
>So look forward to POV-Base, POV-Java, and you better believe there will =
>be a POV-CPP.  This comes when I think the language could benefit from =
>the use of Classes, Multiple Inheritance and Polymorphism.  

Great, that's what we need.  Fragment the language to hell and back so 
nobody stands a chance of understanding every flavor of it.  It's not the 
language that most people want improved, it's the available primitives, 
textures, and transformations.  The one thing I hear asked for over and over 
is nonlinear transformations, but the reason that hasn't been done is nobody 
knows how to do it.

Post a reply to this message

Ron Parker wrote in message <35a39212.0@news.povray.org>...
>Please fix your newsreader to not use quoted-printable for posting.  Then
>turn off that stupid HTML crap and the vCard crap.  This is Usenet, not the
>web.  Thanks.
Sorry...  I like my VCard and my quoted printable...  It stays.

>On Wed, 8 Jul 1998 05:02:48 -0400, Justin Rogers <dig### [at] 3nnet> wrote:
>>    First of all I notice the need for some sort of distributed NetPOV.  =
>>I have many ideas for this and I plan on creating a renderer based on =
>>the DOS version of POV-Ray that does nothing other than render files =
>>with no GUI or any other apparent interface.  It will have support for =
>>multiple frames or for rendering a portion of an image...  Output will =
>>be to file, network stream, internet stream, or any other means I deem =
>>necessary and useful.
>
>You'd do better to start with the Unix source.  This idea has been done to
>death, and even the POV Team has plans to implement it in version 4.
>Before you spend too much time on this, you might want to look at some of
>the available implementations and see if they already do what you're
>trying to do.

I don't want a UNIX binary..  I want something to run Winsock TCP/IP
distributed rendering...  Maybe I didn't clarify myself enough.  And at
current the POV Team has no thoughts of implementing an InetPOV...  So you
are incorrect in assuming I would be wasting my time.

>>    Secondly I find a need for a multithreaded version of the Windows =
>>Executables.  This is so easily done that I almost cry myself to sleep =
>>at night wondering why it wasn't implemented from the beginning.  There =
>
>If you think it's easy to do, then you haven't tried to do it yet.  Let me
>save you some trouble: POV uses a lot of global variables, and they all get
>changed in strange ways at strange times.  If you lock them with critical
>sections, only one thread will be running most of the time anyway.  If you
>don't, you'll corrupt the frame quite quickly.  If you make them all
>thread-local, you'll still be working on it when POV4.0 comes out.

Each thread will work on a seperate part of the image with it's own set of
global variables...  I have looked at the source and it isn't hard to do at
all.  My proposal would be the same as running 4 versions of POV each
rendering say 1/4 of the picture.  This is easily done and each thread could
have its own thread-local.  And it would be very easy to implement.  Don't
think of things in such a narrow minded, one directional approach.  There is
always someone with a workable idea.  Try to support such people instead of
discouraging creativity.  You'll find it is much more beneficial.

>I have some code I wrote for my motion-blur patch that would help with
>multithreading, because it moves most of the globals into the frame
structure
>where they belong, but even I don't have the hubris to believe that
>multithreading would be "easy."
>
>>will be several options that can be set to determine exactly how many =
>>threads and how you are going to use those threads...  Options will be a =
>>-Threads option for declaring a number of threads (more threads would =
>>even speed rendering on a single processor machine) and specifying =
>
>Nonsense.  Thread switching is a very processor-intensive operation.  That
>processor time could be better used doing rendering.  If you run more than
>one rendering thread on a single-processor machine, I can guarantee it'll
be
>slower overall.  It would only be faster on IO-bound processes, and
rendering
>isn't one.

Quit talking about crappy OSes...  Windows NT has no problem thread
switching.  And the only reason 3DSMax and Bryce3D are so quick is because
they are multithreaded...  Single-Threaded versions are clearly and
decisively slower in the rendering process.  Also check Ray Dream Studio...

>>    Thirdly an enhancement to the editor is wanted...  You guys say that =
>>the editor is not able to be written to?  Well a little bit of =
>>subclassing of the edit control associated with the editor window might =
>>do you good.
>
>Uh-huh.  Sure.  Whatever.  Look, we're not morons, okay?  Subclassing would
>be at best a kludge.  Among other things, it wouldn't set the variable that
>POV checks to know when a file has changed.  No, thanks, we'll do it the
>right way if we do it at all.

Again your being narrow minded...  Why does POV need to know when a file has
been changed...  As long as some means is enabled to save a file.  And yes
when you subclass POV you can trap other messages essential to file saving
if that is what you intend to do.  Not to mention an entirely new editor can
be written and put in place of the EditDll.dll.  This is the method I plan
on implementing...  This way you can swap out editors just like a
GUI-Extension.  All you have to do is rename the EditDll.dll file, place the
new one in place and continue on.  Not to mention a rewrite of this dll to
support ActiveX and OLE would be a definite enhancement.

>>But that is not my main goal in the editor department.  I =
>>plan on expanding my DevStudio Add-In to use more of the features of POV =
>>and I plan on doing my editing from within this environment due to it's =
>>syntax coloring and advanced help features.  Not to mention =
>>auto-completion which will be added in DevStudio 98/99 whenever it is =
>>available such as it works in Visual Basic 5.0 now.
>
>This would actually be nice.  I wouldn't mind having that myself.  Can it
>shell out to POV as well?

    It sure can... I have added support for all of the command line options
and all of the command line options can be contained in an ini file.  When
you create a new POV project it automatically creates a .pov file and a .ini
file for you.  Then all you have to do is edit the .ini file and hit the
compile button.  Next thing you know your left with an onscreen POV image or
it has been shelled to disk and POV will auto-exit.  Not to mention it has
support for opening multiple versions of POV to do multithreaded frames.

>>    Fourthly I hear everyone complaining about more features and more =
>>powerful commands in POV...  Well I plan on expanding POV-Ray to make =
>>use of all of the lexical conventions of several different languages...  =
>>So look forward to POV-Base, POV-Java, and you better believe there will =
>>be a POV-CPP.  This comes when I think the language could benefit from =
>>the use of Classes, Multiple Inheritance and Polymorphism.
>
>Great, that's what we need.  Fragment the language to hell and back so
>nobody stands a chance of understanding every flavor of it.  It's not the
>language that most people want improved, it's the available primitives,
>textures, and transformations.  The one thing I hear asked for over and
over
>is nonlinear transformations, but the reason that hasn't been done is
nobody
>knows how to do it.

    Well.  Let me look into such things...  The code is probably out there
somewhere.  And there is probably some other program that implements such
things...  I'll look such code over and hopefully such a thing could be
accomplished...  (I used such quite a few times didn't I ;o)

Post a reply to this message

Attachments:
Download 'Justin Rogers.vcf.txt' (1 KB)

On Wed, 8 Jul 1998 21:46:05 -0400, "Justin Rogers" <dig### [at] 3nnet>
wrote:

>I don't want a UNIX binary..  I want something to run Winsock TCP/IP
>distributed rendering...  Maybe I didn't clarify myself enough.  And at
>current the POV Team has no thoughts of implementing an InetPOV...  So you
>are incorrect in assuming I would be wasting my time.

Did I say Unix binary?  Nope, guess not.  The Unix source just
compiles better for a Win32 console-mode executable, is all, but if
you want to spend time hacking out the display support from the DOS
version, I won't stop you.  Never let the advice of someone who's been
there discourage you from reinventing the square wheel, I always say.

And the POV-Team has stated on this very server that they plan to
implement internet distributed rendering in POV 4.0.  They've had a
well-known port registered with IANA since the days of POV 2.0.

>There is
>always someone with a workable idea.  Try to support such people instead of
>discouraging creativity.  You'll find it is much more beneficial.

I do.  But I haven't seen any such people lately.  Have it your way,
though.  I certainly can't stop you.

>Quit talking about crappy OSes...  Windows NT has no problem thread
>switching.  And the only reason 3DSMax and Bryce3D are so quick is because
>they are multithreaded...  Single-Threaded versions are clearly and
>decisively slower in the rendering process.  Also check Ray Dream Studio...

Sorry, NT _is_ my primary OS and I'm still telling you that
multithreading rendering on a single processor is a waste of time, and
that thread switching is inefficient.  Those other raytracers might be
multithreaded, but it's a matter of the UI being in one thread and the
renderer in another, just like in POV.  Again, if you choose to
believe your own fantasy version of what the world is like, I can't
stop you.

>Again your being narrow minded...  Why does POV need to know when a file has
>been changed...  As long as some means is enabled to save a file.  

Duh... so it can ask you if you want to save before it exits?

>Not to mention an entirely new editor can
>be written and put in place of the EditDll.dll.  This is the method I plan
>on implementing...  This way you can swap out editors just like a
>GUI-Extension.  All you have to do is rename the EditDll.dll file, place the
>new one in place and continue on.  Not to mention a rewrite of this dll to
>support ActiveX and OLE would be a definite enhancement.

This method has been proposed before in this group. In fact, it was I
who proposed it.  But if you read the new POVLEGAL you'll see that
ActiveX and OLE interfaces are out of the question, as is extending
the POV<->EditDLL interface.  In any case, the POV team is completely
revamping the editor for 3.1, so let's see what's in the final version
before we continue complaining about it.

>    It sure can... I have added support for all of the command line options
>and all of the command line options can be contained in an ini file.  When
>you create a new POV project it automatically creates a .pov file and a .ini
>file for you.  Then all you have to do is edit the .ini file and hit the
>compile button.  Next thing you know your left with an onscreen POV image or
>it has been shelled to disk and POV will auto-exit.  Not to mention it has
>support for opening multiple versions of POV to do multithreaded frames.

Could you post it somewhere?  If you lack for FTP space, Twyst might
be able to help you out.

Post a reply to this message

>Could you post it somewhere?  If you lack for FTP space, Twyst might
>be able to help you out.

    Since this is the one idea that you guys seem interested in I'll go
ahead and package and edit the source to be installed on other machines... I
didn't write my code for the editor to be moved around and there are quite a
few init files, registry entries, and version specific things going on with
the editor that have to be cleared up.  Such as this extension of MSDEV
won't work unless you have SP3 installed an the works....  Give me about a
week to pack it up and finish adding keywords for highlighting purposes.
Many of POVs keywords aren't color coded yet and I don't have a dialog that
allows you to customize colors and I haven't yet broken the keywords into
classes for color coding purposes anyway...

    So this in mind I'll get to work and put out my MSDEV extension to the
POV coding world.

Post a reply to this message

Attachments:
Download 'Justin Rogers.vcf.txt' (1 KB)

Hi Justin Rogers, you recently wrote in povray.programming:

> Single-Threaded versions are clearly and
> decisively slower in the rendering process.  
You can't apply an observation from a commercial program to general
software! Maybe the single-threaded ones were badly written, and the
multi-threaded ones were rewritten. Maybe it's a subjective impression
because the UI was more responsive (seperate UI and render thread). 

> And the only reason 3DSMax and Bryce3D are so quick is because
> they are multithreaded...  
Just because some commercial apps have multithreading, doesn't make
them render faster. I doubt that more than one thread is used for
rendering (unless it's running on a multiple CPU machine).

It's totally illogical that POV-Ray could render a scene faster with
more than one rendering thread. If you don't think so, I'd like to
know how this is supposed to work, because then I'll create a thread
for every pixel and have the image rendered faster than you can
blink<g>.

- Lutz
  email : lut### [at] stmuccom
  Web   : http://www.stmuc.com/moray

Post a reply to this message

Ron Parker wrote:

> The one thing I hear asked for over and over
> is nonlinear transformations, but the reason that hasn't been done is nobody
> knows how to do it.


Well, I will not claim I know how to do it, but I will attempt to do it in the
long term. I have pretty clear ideas about non-linear transformations and I have
way enough math knowledge to carry this out. Only, I won't tell any one about it
until I have something working to show and that may take me a year or two (maybe
more at the rate I am programming these days : almost nothing in the past few
months).

Keep the suspens !
Cheers,
Al.

--
ANTI SPAM / ANTI ARROSAGE COMMERCIAL :
Pour me répondre, veuillez enlever le Z de mon adresse.
To answer me, please take out the Z from my address.

Post a reply to this message

Justin Rogers wrote:
> 
> Ron Parker wrote in message <35a39212.0@news.povray.org>...
> >Please fix your newsreader to not use quoted-printable for posting.  Then
> >turn off that stupid HTML crap and the vCard crap.  This is Usenet, not the
> >web.  Thanks.

> Sorry...  I like my VCard and my quoted printable...  It stays.

Then you should expect flames.

I *don't* like quoted-printable etc. either.

tim

Post a reply to this message

>This is so easily done that I almost cry myself to sleep at night wondering why
>it wasn't implemented from the beginning.  There will be several options that

No offence meant, but it's obvious that you haven't done any significant amount
of Windows programming. I presume you are referring to running threads on
multiple processors (there's no point whatsoever in having more than the two
threads that POVWIN currently uses of that's not what you mean).

Any suggestion that the rather major amount of work needed to make POVWIN
internally parallel is 'easily done' is rather absurd, IMO. It would be a quite
major undertaking.

Post a reply to this message

>distributed rendering...  Maybe I didn't clarify myself enough.  And at
>current the POV Team has no thoughts of implementing an InetPOV...  So you

Can you speak on our behalf ? I don't recall telling you so. I'm sure no other
member has done so either.

>Each thread will work on a seperate part of the image with it's own set of
>global variables...  I have looked at the source and it isn't hard to do at

Which means major modifications to the POV source. You would have to make
almost every single global variable thread-local, plus the frame as well.

>all.  My proposal would be the same as running 4 versions of POV each
>rendering say 1/4 of the picture.  This is easily done and each thread could
>have its own thread-local.  And it would be very easy to implement.  Don't

Unless you have four CPU's what the point ? Running four rendering threads on a
single CPU would be noticably slower than running a single rendering thread on
that same CPU. You've fallen into the old 'more threads are faster' trap.
Believe me, it will NOT make rendering faster on ANY single-CPU operating
system.

>Quit talking about crappy OSes...  Windows NT has no problem thread

Please don't be so rude - the other user was giving you quite good advice. It
doesn't matter what the OS is. If a thead switch takes any more than zero time
(which it must) then the time spent swapping threads is time wasted that could
have been better spent rendering the image. Don't fool yourself by thinking
that it takes 'amost no time'. Time is time, no matter how short it is.
Multiply that small time by a few hundred-million thread switches (possible on
a very long render) and you'll get a quite significant performance loss.

>Again your being narrow minded...  Why does POV need to know when a file has
>been changed...  As long as some means is enabled to save a file.  And yes

So when you press the 'render' button it knows whether to read the file from
disk or prompt the user to read it from memory (or another location). Amongst
other things.

You've got a lot of ideas here but going for the throat of people who tell you
that what you suggest isn't as easy as you think isn't the way to go about
things.

Post a reply to this message

If you don't like the v-card, dont read the message, who cares what you like?

tim jordan wrote:

> Justin Rogers wrote:
> >
> > Ron Parker wrote in message <35a39212.0@news.povray.org>...
> > >Please fix your newsreader to not use quoted-printable for posting.  Then
> > >turn off that stupid HTML crap and the vCard crap.  This is Usenet, not the
> > >web.  Thanks.
>
> > Sorry...  I like my VCard and my quoted printable...  It stays.
>
> Then you should expect flames.
>
> I *don't* like quoted-printable etc. either.
>
> tim

Post a reply to this message

Ron Parker wrote in message <35a39212.0@news.povray.org>...

<A lot clipped>

>Great, that's what we need.  Fragment the language to hell and back so
>nobody stands a chance of understanding every flavor of it.  It's not the
>language that most people want improved, it's the available primitives,
>textures, and transformations.  The one thing I hear asked for over and
over
>is nonlinear transformations, but the reason that hasn't been done is
nobody
>knows how to do it.
>

The last bit about the non-linear transformations....

Don't have any idea how to do this but something like

matrix {
    <formula,formula,formula>

etc

Sorta like a translation matrix.

So to get the new point, take old point and move( change) by formula amount.

Just an idea. anyway


Fran.

Post a reply to this message

> The last bit about the non-linear transformations....
> [...clipped...]
> So to get the new point, take old point and move( change) by formula amount.

I've been thinking about this one, too (non-linear transformations).
It's a difficult problem. It would be easy (relatively) to take a shape
and skew it based on some function. However, I think there would be a
lot of work to also take into account surface normal, textures and
everything else which dictates what an object would look like at a
skewed point. I don't think it is impossible at all, just a very tricky
and uncomfortable problem. I sure ain't the guy to take on that one!

jb

Post a reply to this message

Fran wrote:
>The last bit about the non-linear transformations....
>
>Don't have any idea how to do this but something like
>
>matrix {
>    <formula,formula,formula>
>
>etc
>
>Sorta like a translation matrix.

I am not sure, but a matrix may not work. I would try to deform the *RAY*, not the
object. This is the suggested method in "An introduction to ray tracing", page 115 -
"Deformed surfaces".


Thorsten

Post a reply to this message

On Sun, 12 Jul 1998 23:41:05 +0200, Thorsten Froehlich 
      <Tho### [at] compuservecom> wrote:
>Fran wrote:
>>The last bit about the non-linear transformations....
>>
>>Don't have any idea how to do this but something like
>>
>>matrix {
>>    <formula,formula,formula>
>>
>>etc
>>
>>Sorta like a translation matrix.
>
>I am not sure, but a matrix may not work. I would try to deform the *RAY*, 
>not the object. This is the suggested method in "An introduction to ray 
>tracing", page 115 - "Deformed surfaces".

Right, matrices won't work.  By definition, anything that can be represented
as a matrix is linear.  But Fran wasn't talking about what mathematicians 
traditionally call a matrix; he was talking about a notational system that
superficially resembles the one POV now uses for linear transformations.

POV now works by deforming the ray, and this works fine for invertible linear 
transformations, because a ray is still a ray after transformation.  With a 
nonlinear transformation, though, assuming you can even figure out how to 
invert it, the ray would end up being a curve of some type.  A number of 
objects already require the raytracer to solve a nasty polynomial to find the 
intersection with a straight line.  In general, the problem of intersection 
with an arbitrary curve might be so difficult as to be practically 
impossible.  Still, it might be possible to work with perspective 
transformations, because they also map lines to lines. They aren't always
invertible, though, so you'd have a problem with a ray that intersected such 
a surface at a singularity.  That's why zero is an illegal value in a scale.

The problem of general nonlinear transformations would likely only be solved 
by converting the object to a mesh and then using the forward transform on 
its constituent elements, but unless the inverse transform is easily 
calculable, I don't see how you could transform the texture as well.  

This brings us back to the problem of making a mesh from arbitrary objects,
which would be really, really nice but perhaps not terribly easy.  If we had
it, though, we could do a lot of other neato things we can't now, like real 
radiosity, conversions from POV to other formats like VRML, OpenGL preview,
and displacement mapping.  The object orientation of POV means that it could
have each object be responsible for its own mesh generation, and at least in
the short term it could just punt to an error message for objects that don't
know how to do so, just as POV does now for the insideness test on meshes.
Objects that might require this treatment are the polynomial surfaces.

If we wanted something useful, though, the bare minimum would be for CSG
operations to be able to do mesh generation by working with the meshes 
generated by sub-objects.  To me, this seems like the difficult part of the
job.

Post a reply to this message

Ron Parker wrote:
>Right, matrices won't work.  By definition, anything that can be represented
>as a matrix is linear.  But Fran wasn't talking about what mathematicians 
>traditionally call a matrix; he was talking about a notational system that
>superficially resembles the one POV now uses for linear transformations.

I am not sure I fully understand what you are refering to English isn't my native
language), can you expail this a little bit more, please?

Ron Parker wrote:
>POV now works by deforming the ray, and this works fine for invertible linear 
>transformations, because a ray is still a ray after transformation.  With a 
>nonlinear transformation, though, assuming you can even figure out how to 
>invert it, the ray would end up being a curve of some type.  A number of 
>objects already require the raytracer to solve a nasty polynomial to find the 
>intersection with a straight line.  In general, the problem of intersection 
>with an arbitrary curve might be so difficult as to be practically 
>impossible.

To keep it simple (and possibly not covering all cases) a quadartic function (for each
component of the vector) would be enough to make an egg out of a sphere.

Ron Parker wrote:
>The problem of general nonlinear transformations would likely only be solved 
>by converting the object to a mesh and then using the forward transform on 
>its constituent elements, but unless the inverse transform is easily 
>calculable, I don't see how you could transform the texture as well.  

Splines could be used so solve this problem as well, couldn't they?

Ron Parker wrote:
>This brings us back to the problem of making a mesh from arbitrary objects,
>which would be really, really nice but perhaps not terribly easy.  If we had
>it, though, we could do a lot of other neato things we can't now, like real 
>radiosity, conversions from POV to other formats like VRML, OpenGL preview,
>and displacement mapping.  The object orientation of POV means that it could
>have each object be responsible for its own mesh generation, and at least in
>the short term it could just punt to an error message for objects that don't
>know how to do so, just as POV does now for the insideness test on meshes.
>Objects that might require this treatment are the polynomial surfaces.

Yes, to generate meshes out of objects is an important feature missing. But I think it
is no (too big) problem to determine the surface of any polynomial defined object,
however I have never tried so I cannot claim this to be right.
But having a few million triangles and all their energies, etc. to calculate the
radiosity with a itterative approach (not to talk about a full matrix inversion) will
still not be easier or faster. And inorder to use raytracing with it you would have to
re-apply the light (energy) data to the objects as something like a texture. Or you
would only be able to render with radiosity and meshes. Not to talk about the
reflection problem (e.g. mirrors) which is still (???) there with radiosity based on
meshes.

Ron Parker wrote:
>If we wanted something useful, though, the bare minimum would be for CSG
>operations to be able to do mesh generation by working with the meshes 
>generated by sub-objects.  To me, this seems like the difficult part of the
>job.

Yes, it is! Especially if you deal with more than one object it is hard to find out if
a specific part of an object (or to be more precise, the part of the objects mesh) is
to be displayed (and therefore a part of the surface), or not. I have tried to write a
program to do this (as a demo only - no real application!), but I ran exactly into
this problem. I have not done much more research to solve this because gettting the
Macintosh POV-Ray 3.1 beta ready was more urgent :-(  And other of the POV-Ray team
warned me that (my approach, like others) might not work. But I am still confident I
can get it to work if I spend more time with it!   Analysis is not my hobby math
subject, geometry is (with the as few polynoms as possible :-)


Thorsten

Post a reply to this message

On Mon, 13 Jul 1998 21:48:45 +0200, Thorsten Froehlich 
<Tho### [at] csicom> wrote:
>Ron Parker wrote:
>>Right, matrices won't work.  By definition, anything that can be represented
>>as a matrix is linear.  But Fran wasn't talking about what mathematicians 
>>traditionally call a matrix; he was talking about a notational system that
>>superficially resembles the one POV now uses for linear transformations.
>
>I am not sure I fully understand what you are refering to English isn't my native
language), can you expail this a little bit more, please?

I'm not sure how to explain this.  I just meant that he wasn't talking about
what you and I might call a matrix.  He was only talking about a syntactic
way to express an array of formulas.

>To keep it simple (and possibly not covering all cases) a quadartic function (for
each component of the vector) would be enough to make an egg out of a sphere.

A perspective transformation is sufficient to transform a sphere into an
egg.  Unfortunately, a perspective transformation can also turn a sphere into 
a weird barbell-shaped thing with a singularity in the middle.  In general, 
it might not be possible to transform the ray into the space of the object 
when using perspective transformations because working with rays passing 
through the singularity would require dividing by zero.  Also the concept of 
"inside" is seriously messed up by the presence of singularities.

>Ron Parker wrote:
>>The problem of general nonlinear transformations would likely only be solved 
>>by converting the object to a mesh and then using the forward transform on 
>>its constituent elements, but unless the inverse transform is easily 
>>calculable, I don't see how you could transform the texture as well.  
>
>Splines could be used so solve this problem as well, couldn't they?

Of course.  Anything that can still be tested for intersections after 
undergoing an arbitrary transformation is fine.  The idea is to eliminate
the need for an inverse transformation.

>Yes, to generate meshes out of objects is an important feature missing. But I think
it is no (too big) problem to determine the surface of any polynomial defined object,
however I have never tried so I cannot claim this to be right.

I, too, have no experience with trying to make meshes from higher-order
polynomial surfaces.  They may indeed be easier than I think.  But they can
also be infinite, and depending on what you plan to use the triangles for,
that can be an insurmountable obstacle.

>But having a few million triangles and all their energies, etc. to calculate the
radiosity with a itterative approach (not to talk about a full matrix inversion) will
still not be easier or faster. And inorder to use raytracing with it you would have to
re-apply the light (energy) data to the objects as something like a texture. Or you
would only be able to render with radiosity and meshes. Not to talk about the
reflection problem (e.g. mirrors) which is still (???) there with radiosity based on
meshes.

True, we might not want to try to implement radiosity this way in POV, but 
it might be nice to use some of the great tools available for POV and the 
expressiveness of the POV language to generate data that could be fed into 
other renderers, of which Radiance, OpenGL, and VRML are but obvious 
examples.  

Clearly, there'd have to be extra parameters to control the mesh-generation 
process, so you don't get a few million triangles unless you want or need 
them.

Post a reply to this message

As far as any type of mesh conversion of arbitrary objects, has anyone
checked out Ployray.  Last time i used it (quite a while ago now)
Wireframe was one of the rendering output options. For common primatives
you could use a default uv devision or define your own or use a three
plane projection to find a mesh of the objects. I'm no programmer but
this might be worth a look.

Ben

Post a reply to this message

Fran & Melissa wrote:

> >is nonlinear transformations, but the reason that hasn't been done is nobody
> >knows how to do it.
>
> The last bit about the non-linear transformations....
> Don't have any idea how to do this but something like
> matrix {
>     <formula,formula,formula>
> etc
>
> Sorta like a translation matrix.
> So to get the new point, take old point and move( change) by formula amount.
> Just an idea. anyway


First of all, you really mean a transformation vector rather than a matrix.
Second, this sort of transformation is very easy to do if you want to plot a
number of points, but in ray-tracing, you cast rays and aim at finding out where
the objects intersect these rays, for this reason ray-tracing with a
transformation vector as you suggest is either extremely computer intensive
(many samples to have some sort of accuracy as to where the ray intersects an
object) or impossible if you really want exact intersections (as far as numeric
calculation allows) because for most of these mathematical equations it is
impossible to have a set of equations that describe the set of solutions. So you
have to give up this very nice fancy idea and restrict it to an easier
mathematical game, for example if you limit your functions to polynoms of degree
2, that makes it degree 6 as a whole, for this there exists powerful root
solvers. Such functions can be nice but you pretty quickly find lots of limits
to what you can do with them, you can only distort your objects in some set
patterns, nothing really weird. Another step is to look for more complex
equations for which we can find roots with a few iterations (not many), ... I'm
working on that sort of possibility but you'll have to wait a few years, unless
someone else comes up with it before I do.

Cheers,
Al.

--
ANTI SPAM / ANTI ARROSAGE COMMERCIAL :
Pour me répondre, veuillez enlever le Z de mon adresse.
To answer me, please take out the Z from my address.

Post a reply to this message

Ron Parker <ron### [at] rongwmicrocom> wrote:

> The one thing I hear asked for over and over 
> is nonlinear transformations, but the reason that hasn't been done is nobody
> knows how to do it.

It is possible to do (but slow) by expressing the objects as 
mathematical isosurfaces and creating new composite functions that
distorts the object. The following code should work with the isosurface
patch of povray.

------
#declare F1 = function { .... my object ... }
#declare F2 = function { F1(x+noise3d(x,y,z),y+x*x,z) }

isosurface { .... F2 ... }
------

The function F2 declared above would distort the object F1 by
bending it along the y-axis as well as making it 'jagged' along
the x-axis. (At least I think so, haven't tried it yet).

The only problem (despite the speed) with doing this with arbitrary 
objects might be the difficulty with expressing them as mathematical
objects. But as long as all the primitive functions and the 
CSG-operations can be expressed mathematically this should not
be any serious problem.

/ Mathias

PS. For those who don't know what an isosurface object is, it is
an object expressed by a mathematical function where the "inside points"
of the objects evaluate to a value less than zero and the "outside 
points" evaluate to greater than zero.
Example: x*x + y*y + z*z - 1.0   defines a sphere of radius 1
.DS

Post a reply to this message

In article <35a420e1.0@news.povray.org>, "Justin Rogers" <dig### [at] 3nnet> wrote:
> Each thread will work on a seperate part of the image with it's own set of
> global variables...  I have looked at the source and it isn't hard to do at
> all.  My proposal would be the same as running 4 versions of POV each
> rendering say 1/4 of the picture.  This is easily done and each thread could
> have its own thread-local.  And it would be very easy to implement.  Don't
> think of things in such a narrow minded, one directional approach.  There is
> always someone with a workable idea.  Try to support such people instead of
> discouraging creativity.  You'll find it is much more beneficial.

   *hehehe* isn't that cute? He thinks threads are free :)
   Why don't you run a separate thread for each pixel? That would be, for
a moderate 640x480, 307,200 threads. With that many threads, the rendering
will be over before it has even begun! Then we can all go home ;)

   Chris Johnson (in all seriousness- try mixing creativity with
willingness to _listen_ to what people are telling you ;) )
         @airwindows.com
   chrisj

Post a reply to this message

"Jon S. Berndt" wrote:

> I've been thinking about this one, too (non-linear transformations).
> It's a difficult problem. It would be easy (relatively) to take a shape
> and skew it based on some function. However, I think there would be a
> lot of work to also take into account surface normal, textures and
> everything else which dictates what an object would look like at a
> skewed point. I don't think it is impossible at all, just a very tricky
> and uncomfortable problem. I sure ain't the guy to take on that one!

Transforming normals isn't too hard.  I don't remember the formula
offhand for deriving the normal-transformation matrix from the
point-transformation matrix, but it's in Andrew Glassner's "Graphics
Gems".
-- 

Mike Paul
mbp### [at] lockeccilorg
http://www.worldaxes.com/paul_fam

Post a reply to this message

On Sat, 11 Dec 1999 23:17:40 -0500, Michael Paul wrote:
>"Jon S. Berndt" wrote:
>
>> I've been thinking about this one, too (non-linear transformations).
>> It's a difficult problem. It would be easy (relatively) to take a shape
>> and skew it based on some function. However, I think there would be a
>> lot of work to also take into account surface normal, textures and
>> everything else which dictates what an object would look like at a
>> skewed point. I don't think it is impossible at all, just a very tricky
>> and uncomfortable problem. I sure ain't the guy to take on that one!
>
>Transforming normals isn't too hard.  I don't remember the formula
>offhand for deriving the normal-transformation matrix from the
>point-transformation matrix, but it's in Andrew Glassner's "Graphics
>Gems".

There's a function (or perhaps a macro) for this in POV, too, but it assumes
that your transformation is a matrix, which a nonlinear transformatio isn't,
by definition.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message