 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> So, is this to say that POV-Ray will "officially" support clusters? Or
> are you saying this opens the door for the developer community to create
> a patch to do so, such as a form of POV-Ray that would work seamlessly
> with IMP, for example?
At the moment we are concentrating on making sure the infrastructure exists
internally to allow us to separate the concept of user interface and renderer
which originally had a one-to-one relationship. That is, for each scene file
being parsed there was exactly one user interface (even if command-line), and
for each sucessfully-parsed scene file there was exactly one render started,
after which the parsed data was deleted from memory.
Since implementing the SMP support required us to basically rip the code
apart and bolt it back together again without the use of the literally
hundreds of global variables and other bits of writable shared data which
wouldn't work with multiple threads, we took the opportunity to implement
what is known as the 'document/view' model (this is what is used by many MDI
programs based on MFC, though of course our code has nothing to do with that
other than sharing the concept).
With respect to the doc/view concept, a parsed scene is a 'document' and a
render is a 'view'. The 'document' is everything in the scene except the
camera settings, and the 'view' is the camera settings, output resolution,
output file type, gamma correction, and so forth. Each document and view has
its own internal identifier and the POV-Ray code uses these ID's when
communicating between the front and back ends of the codebase. When a scene
is succesfully parsed the frontend is told about it, and it then using that
ID creates a view and subsequently asks the backend to render that view.
The parse and render stages are therefore now quite distinct and in
particular the render requires an explicit command from the frontend
referencing the parsed scene's ID to kick off the actual tracing.
What this also implies should now be clear: a parsed scene ('document') is a
separate object that has its own lifetime. It does not automatically vanish
once a render is successful; we have to explicitly delete it. And also that
you can have more than one render ('view') of a document from different
camera positions without re-parsing the scene. And furthermore you can have
more than one document in memory at once and be rendering one or several
views of those documents at any given time (presuming you have the resources
and CPU horsepower to make it practical).
There are still a few restrictions in the backend code making a simultaneous
multi-scene render impractical but the code as a whole already works exactly
as I have described.
You may note therefore - since the frontend and backend have the concept of
"document id's" - that this meshes in nicely with the ability of a frontend
to be in a different *place* than the backend. We don't pass pointers around
between the user-interface and renderer anymore, we refer to resources in a
more abstract way. Coupled with the fact that we use message-passing
interface that is not sensitive to the local machine's word size or
endianness, the ability to have remote renders just comes naturally.
However (and yes there is a however), we currently have no user-interface
support for this and don't plan on adding it anytime in the near future as
we're busy with the core code. Plus there's no transport (e.g. tcp) or
authentication support written yet.
Getting back to your original question: as you can see it's clear that
network support could be implemented by someone else. However I feel that
it is best done by us because (a) I don't want a raft of incompatible network
implementations out there, and (b) properly thought-out authentication and
security is essential if we want this to take off. We don't want to see POV
get a bad security reputation because someone somewhere does a quick network
port that ends up compromising someone's hardware.
If a group of sufficiently dedicated users wanted to get together and help
hammer out implementation details for networked rendering then I'd be willing
to listen.
Now that's a long reply to a simple question but in the process at least I've
publicly put into hardcopy some of the logic behind the rather large changes
that have been made to POV-Ray 3.7 (and perhaps now some will understand why
each beta takes so long - there's really a huge amount of infrastructure work
in there that we have to deal with and finish, totally apart from the actual
rendering bugs).
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason wrote:
> what is known as the 'document/view' model
Also, in the early days commonly known as model-view-controller concept
(whereas the controller is not directly mentioned in modern paradigms, it is
assumed to be part of the view). The model really is the "model" aka scene
in POV-Ray, the view is the frontend, actually two views, the rendered image
and the scene source. Ideally the text editor would also allow direct
control over the image view (a WYSIWYG paradigm), but of course in POV-Ray
that isn't possible (Moray gets close to that though afaics) as the parser
is in between :-)
As Chris mentions, the complexities in the code POV-Ray are now mostly
hammered out, but the real topic is to get it in a nice, still easy to use
GUI. Hiding the complexities of distributed computers is not trivial, in
particular to do it right, and if possible the first time is really difficult.
Another benefit Chris did not mention explicitly is that finally we can have
the GUIs evolve at a different rate than the rendering core. Previously
extending the GUI always required rather complicated render core changes if
the GUI needed new data. Now we can just say that if a message passes data
from the backend and a particular piece of information is not there, well,
we don't display it, while before it meant a different internal call
structure with different parameters and a whole mess.
In fact, this design process did start with POV-Ray 3.5 already, and it has
been making smaller steps with every release of POV-Ray since then. Now
with POV-ray 3.7 all these internal changes for the message-driven control
that have been going on for five years now finally show results and
*improvements* for users. Especially for POV-Ray 3.6 a lot was done already
in cleaning up the early 3.5 implementation of this. So anybody who had a
look at the 3.6 or 3.5 source code and thought "Why do they do all this
complicated message passing abstraction just to turn it into text again ten
calls down the call chain ?" has their answer - it was of tremendous help to
get clean SMP support working to some extend within less than one month!
Nevertheless, as you can see, doing proper and clean SMP support is a
massive task and nothing a simple patch could ever have established (the
existing patches for distributed rendering just run multiple copies of
POV-Ray and duplicate *all* scene data). In the end, we will probably have
"invested" two full-time developer years into getting the POV-Ray 3.7 core
to do SMP, and that doesn't even include any new features or the GUI frontends!
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Cason" <nos### [at] deletethis povrayorg> wrote in message
news:4356bfa0@news.povray.org...
>
> What this also implies should now be clear: a parsed scene ('document') is
a
> separate object that has its own lifetime. It does not automatically
vanish
> once a render is successful; we have to explicitly delete it. And also
that
> you can have more than one render ('view') of a document from different
> camera positions without re-parsing the scene. And furthermore you can
have
> more than one document in memory at once and be rendering one or several
> views of those documents at any given time (presuming you have the
resources
> and CPU horsepower to make it practical).
>
Does this mean that a parsed scene object will exist that might one day be
saveable to disk that might later be reloaded and rerendered with a
different
view with no need for reparsing?
Pan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
pan wrote:
> Does this mean that a parsed scene object will exist that might one day be
> saveable to disk that might later be reloaded and rerendered with a
> different view with no need for reparsing?
A "parsed scene object" always has and always will exist. The scene
structure has to be in memory to be rendered, POV-Ray always worked this
way. This has nothing to do with the ancient - and useless, dig in
povray.programming around 1998 to 2000, there is more than one thread about
this there - binary scene file "idea". To summarise thsoe discussions, a
"binary" scene file format would not make loading a scene faster, nor offer
any other benefit compared to the paser as it is.
Either way, the changes in POV-Ray 3.7 having nothing to do with the parser
in the first place anyway.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> about this there - binary scene file "idea". To summarise thsoe
> discussions, a "binary" scene file format would not make loading a scene
> faster, nor offer any other benefit compared to the paser as it is.
It could fill up a significantly larger area of storage for some scenes,
though :)
Sorry, I couldn't resist.
--
~Mike
Things! Billions of them!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
abyss.pov is still rendering incorrectly (ie. with a black background).
I also noticed that stackergold.pov takes 10 times longer to parse
with pov3.7beta10 than it takes with pov3.6.1 (21 seconds vs 2 seconds
in my computer).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> abyss.pov is still rendering incorrectly (ie. with a black background).
Noted, thanks, this has still to be addressed.
> I also noticed that stackergold.pov takes 10 times longer to parse
> with pov3.7beta10 than it takes with pov3.6.1 (21 seconds vs 2 seconds
> in my computer).
Good find, thanks ... this is caused by the fact that as of this beta each
attempt to open a file causes a call to the frontend that has to be replied
to (the frontend controls locating files and granting access permission, and
in the long term - once support is added - can even send the file contents to
the backend via POVMS).
Obviously this has to be made more efficient; for some reason the results
aren't being cached though they are supposed to be (stackergold's use of
macros causes a lot of file access).
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason wrote:
> POV-Ray 3.7.beta.10 is available from http://www.povray.org/beta/.
>
> This beta is currently for the Windows platform only and includes standard,
> SSE2, and 64-bit binaries.
And for some reason also beta 9..
-r
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason <nos### [at] deletethispovrayorg> wrote:
> Warp wrote:
> > abyss.pov is still rendering incorrectly (ie. with a black background).
>
> Noted, thanks, this has still to be addressed.
>
> > I also noticed that stackergold.pov takes 10 times longer to parse
> > with pov3.7beta10 than it takes with pov3.6.1 (21 seconds vs 2 seconds
> > in my computer).
>
> Good find, thanks ... this is caused by the fact that as of this beta each
> attempt to open a file causes a call to the frontend that has to be replied
> to (the frontend controls locating files and granting access permission, and
> in the long term - once support is added - can even send the file contents to
> the backend via POVMS).
>
> Obviously this has to be made more efficient; for some reason the results
> aren't being cached though they are supposed to be (stackergold's use of
> macros causes a lot of file access).
>
> -- Chris
I saw the same issues using the 64bit version running woodenbox.pov
AMD64 +4000 2GB-DDR400 nVidia 6800 SLI
version 3.6 @ 512x384 no/AA = 3.53seconds or 55676.66pps
version 3.7.0 beta10 @ 512x384 no/AA = 12.59seconds or 15612.48pps
*Alan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason wrote:
> With respect to the doc/view concept, a parsed scene is a 'document' and a
> render is a 'view'. The 'document' is everything in the scene except the
> camera settings, and the 'view' is the camera settings, output resolution,
> output file type, gamma correction, and so forth. Each document and view has
> its own internal identifier and the POV-Ray code uses these ID's when
> communicating between the front and back ends of the codebase. When a scene
> is succesfully parsed the frontend is told about it, and it then using that
> ID creates a view and subsequently asks the backend to render that view.
Would this also allow a "portal" texture type to be used, where the
surface of an object is basically a "view" of a separate "document"?
...Chambers
(...after a long hybernation)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
