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 :

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