POV-Ray : Newsgroups : povray.programming : Clarifying some issues and a General RFC Server Time
29 Jul 2024 12:26:55 EDT (-0400)
  Clarifying some issues and a General RFC (Message 4 to 13 of 23)  
<<< Previous 3 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Ronald L  Parker
Subject: Re: Clarifying some issues and a General RFC
Date: 8 Jul 1998 23:35:35
Message: <35a6268c.78947931@news.povray.org>
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

From: Justin Rogers
Subject: Re: Clarifying some issues and a General RFC
Date: 9 Jul 1998 00:31:32
Message: <35a43994.0@news.povray.org>
>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)

From: Lutz Kretzschmar
Subject: Re: Clarifying some issues and a General RFC
Date: 9 Jul 1998 15:03:54
Message: <35a4eab5.21233171@194.174.214.10>
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

From: Alain CULOS
Subject: Re: Clarifying some issues and a General RFC
Date: 9 Jul 1998 18:03:20
Message: <35A3F1E4.D5BEC2A4@bigfoot.com>
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

From: tim jordan
Subject: Re: Clarifying some issues and a General RFC
Date: 9 Jul 1998 22:10:11
Message: <35A5695E.7DFC@paradise.net.nz.nospam>
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

From: povray org admin team
Subject: Re: Clarifying some issues and a General RFC
Date: 10 Jul 1998 12:14:55
Message: <35a72f4e.34175161@news.povray.org>
>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

From: povray org admin team
Subject: Re: Clarifying some issues and a General RFC
Date: 10 Jul 1998 12:27:05
Message: <35a930a4.34517343@news.povray.org>
>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

From: Tim Burton
Subject: Re: Clarifying some issues and a General RFC
Date: 10 Jul 1998 14:33:31
Message: <35A650E8.ED09DDF6@Thrt.Com>
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

From: Fran & Melissa
Subject: Re: Clarifying some issues and a General RFC
Date: 12 Jul 1998 14:55:36
Message: <35a8f898.0@news.povray.org>
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

From: Jon S  Berndt
Subject: Re: Clarifying some issues and a General RFC
Date: 12 Jul 1998 18:37:24
Message: <35A92DB0.FC4B4604@hal-pc.org>
> 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

<<< Previous 3 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.