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)