I would like to mention that I like EI camera, and I like renderama when render animation, but in rendering still images (5000 x 4000 pixel or higher) I don’t get the speed I want, and I have 2 dual core PC here, which I can start 4 camera render 4 strips, but the speed I gain is not that much in GI Still compare to animation...I think it is about 50% instead of 300-400%
I understand it is a bit difficult to recode a MP camera, but is there any way to made camera render faster in still images, without heavy work on camera?
Sorry, but we really don’t know how to make a program much faster without heavy work About all this MP polemics.. try to be a bit philosophic (don’t know how to explain better). “Iron race” has no end. How about, say, porting to 64-bits? Also necessary, isn’t it? Then it will be a time for a new OS from Apple (quite in their style). But hey, when to fill a program with new content, new features? There are no companies (even with deep pockets) that do a next porting immediately after previous one. So, there is no any catastrophe, but just news about new Mac
Hmm… plus initiative of Brian LOL
And another one: don’t overestimate MP potential. Not near all can be parallelized. Strictly speaking, OS itself is NOT thread-safe. Shading and, yes, ray-tracing - practically only these 2 are subjects of parallel work. Many and many others are not: geometry creation, displacement, ray-trace setup, anti-aliasing, input/output etc. etc.
How about a “special effects” addition to Camera that could accept “plugins”.
This would be a built in postprocessing engine that would handle adding special effects at the end of the rendering process.
Too late This one is a part of multi-layers work and it’s already in process.
That is exciting news.
I am eagerly awaiting to see how it works!
If an MP solution for Camera is some time away, do you think there would be any benefit to provide a bridge to hardware specific render engines for EIAS? Perhaps something like this: http://www.artvps.com/page/109/raybox.htm
Just curious.
We think that no. Their software supports 3ds and Maya renderers. Also what to answer for Q that will be immediately asked: “It have a quad Mac (for example). So, why I need to buy a some “box?”
Definitely got a point there. With the advent of Multicore computers, these kinds of systems probably will fade away.
And another one: don’t overestimate MP potential. Not near all can be parallelized. Strictly speaking, OS itself is NOT thread-safe. Shading and, yes, ray-tracing - practically only these 2 are subjects of parallel work. Many and many others are not: geometry creation, displacement, ray-trace setup, anti-aliasing, input/output etc. etc.
Well, I think raytracing parallelization is a great place to start. If anything, its a lot of marketing value to state such a claim. Do you think having an MP camera would actually reduce performance in any way? Seems silly to ask, but maybe Camera’s code is such that parallelization would actually be less efficient?
And another one: don’t overestimate MP potential. Not near all can be parallelized. Strictly speaking, OS itself is NOT thread-safe. Shading and, yes, ray-tracing - practically only these 2 are subjects of parallel work. Many and many others are not: geometry creation, displacement, ray-trace setup, anti-aliasing, input/output etc. etc.
Well, I think raytracing parallelization is a great place to start...Do you think having an MP camera would actually reduce performance in any way? Seems silly to ask, but maybe Camera’s code is such that parallelization would actually be less efficient?
This is a really good question.
Igors- Are there theoretically SOME MP optimizations possible outside of RT/GI? Shouldn’t it be possible to “parallellize” multiple phong shadows? If you have 24 phong lights casting mapped shadows could each shadow be calculated on a separate thread/core?
Igors- Are there theoretically SOME MP optimizations possible outside of RT/GI? Shouldn’t it be possible to “parallellize” multiple phong shadows? If you have 24 phong lights casting mapped shadows could each shadow be calculated on a separate thread/core?
Well, we cannot answer about 24 phong lights - it needs a careful learning of I/O tech. details for all platforms. But, anyway, an optimization outside RT/GI would lost its charm/attractiveness momentary. Cause a typical ratio RT/phong is like 9/1, i.e. 90% (or more) of render time is spent for casting rays and only 10% (or less) for phong shading. For Camera and other render engines as well.
Paralumino - 07 April 2007 09:09 AM
Well, I think raytracing parallelization is a great place to start. If anything, its a lot of marketing value to state such a claim. Do you think having an MP camera would actually reduce performance in any way? Seems silly to ask, but maybe Camera’s code is such that parallelization would actually be less efficient?
We see nothing silly here. Yes, MP (technically: multi-threading) is not compatible with some other optimizations. There are also wastes for threads synchronizations (waiting on semaphores) that can be very significant. But, of course, it does NOT mean that MP is uneeded/ineffective.
But this work has no “start”, “next step(s)”, and “finish”, it can be done only at once and anything other should be blocked until it’s finished. In rough explanation “it’s another one porting” (with all consequences you know). Thus IMO now it’s not a good idea to force user to wait, wait and wait (no matter a goal is 100% reasonable and necessary).
Thank you for the response. I guess we’ll have to find ways to focus attention away from MP integration issue until the time is right. That being the case, how can we make the current Rama MP solution easier and more effective for the user? There are a number of potential improvements that could make Rama better.
Thank you for the response. I guess we’ll have to find ways to focus attention away from MP integration issue until the time is right. That being the case, how can we make the current Rama MP solution easier and more effective for the user? There are a number of potential improvements that could make Rama better.
Ideas anyone?
About Rama/MP. You know our opinion: 3D app should have both. And, of course, MP will be done in future. And 64-bits too. Simply cause there is no other choice/way. BUT: do ALL, NOW and immediately = 100% safe way to crash only.
About “focus RAMA”. We aren’t sure. Did you hear something about EITG plans in this area? We personally - nothing. And if so, why need to focus here if hands are full with other things?
We think the best (and simplest) way is to focus on what is under construction now. Multi-Layers is just an example. Dave said a series of ideas, most of them are coincided with actual plans. But, of course, there is a portion of “dreams”, over-expectations and “plans over plans”. That’s normal, user always wants more (hmm… much more) and he’s not an engineer to be familiar with all details. So, dissolve this component, give people more info (but accurate) and.. you’ve a nice “focus”
About Rama/MP. You know our opinion: 3D app should have both. And, of course, MP will be done in future. And 64-bits too. Simply cause there is no other choice/way. BUT: do ALL, NOW and immediately = 100% safe way to crash only.
About “focus RAMA”. We aren’t sure. Did you hear something about EITG plans in this area? We personally - nothing. And if so, why need to focus here if hands are full with other things?
We think the best (and simplest) way is to focus on what is under construction now. Multi-Layers is just an example. Dave said a series of ideas, most of them are coincided with actual plans. But, of course, there is a portion of “dreams”, over-expectations and “plans over plans”. That’s normal, user always wants more (hmm… much more) and he’s not an engineer to be familiar with all details. So, dissolve this component, give people more info (but accurate) and.. you’ve a nice “focus”
Hello Igors,
Multilayers IS the primary focus for EIAS in v7 right now. I’m not debating that. When I talk about focus, I’m talking about focus in relation to the greater subject of MP..not EI’s current course of direction. I don’t think we should completely change what we’re doing now and divert attention away from Multilayers.
Users want MP. We all know that. But by saying lets “focus” on Rama, I’m suggesting that for the next version (whether v7 or v8) of EIAS we continue to improve the way that program works. The Rama MP solution is acceptible, but clunky. If we streamline the process and provide more features in Rama that not only simplifies the MP task, but also covers deficiencies in the program’s main purpose (distritbuted rendering), users would probably go for that. There are simple things about Rama that could use improvement.
While not wanting to turn this into a general requests thread I want to chime in here. For us, the current Rama solution for rendering on all processors works fine. It isn’t ideal of course but this isn’t because of the concept behind the system (one Camera per processor) but more because Renderama is such a basic utility that could REALLY do with even a .01 update to make it easier to work with; for instance display the rendering camera name in Rama so we know which render is which. That alone would make Rama less ‘blind’.
As for making Camera MT, sure it will happen, but not right now thanks, lets finish making Camera a complete rendering solution and then do it, because given the choice between 10 more features or an MT Camera, right now, I’d choose 10 more features (and then an MT Camera
I’m absolutely delighted with the progress being made on Multi-Layering. And the post-processing FX for Camera sound very interesting indeed.
Happy Easter
Ian
Hmmm…
Better Renderama...Lots of thoughts on that- whether with MP Camera or not.
Auto sensing slaves over a network (using ZeroConf)
Lower I/O overhead. Camera files for every frame become very large, and sometimes saving out Camera control files can take some time. Why not just send a full copy of the project to each slave with “instructions” on which frames to render? It would require “smarter” slaves, but much less I/O and networking overhead.
The old version was really slick...when it worked. The “master” would even get image previews sent back from the slaves. You could visually see the progress on all of the network slaves from the master. The problem was with stability, and not being able to recover easily from a single crashed camera on the network (major headache). It earned the nickname “Render-Trauma”, but feature-wise the old way was better. You could even remote-launch slaves on other machines.
The current version is the complete opposite. Extremely bare bones, but basically bulletproof.
Let’s see some of the old features return, and maintain the stability of the new system.
Rama still makes sense even with an MP enabled Camera (to spool jobs to the render queue, even locally). It would also be good to be able to set a maximum number of threads for an MPCamera. This could leave you with 1 or 2 completely free cores to continue doing other work while 6 or 7 cores rendered “in the background”.
Think about this too…
With the new MacPro we would be running 17 applications to max out renderama. 8 Cameras, 8 “Slaves” and Renderama itself. That’s a tremendous amount of application overhead. I bet renderama and the slaves will eat enough CPU cycles to make 8 Cameras unfeasible, you’d probably only be able to run 7, the eighth would just be supporting all of the renderama apps. You’d probably need another GB of RAM for all of those (although RAM is cheap these days), and just imagine the I/O needs of 8 cameras tugging on all of those render control files at once, and saving out frames and temp files… You may need a heavy duty RAID arrray just to keep up with all of the I/O.
Can’t we streamline this?
Why can’t the “slave” interface be integrated into Camera itself (reducing overhead and setup complexity)
How can the overall I/O be reduced?
With the new MacPro we would be running 17 applications to max out renderama. 8 Cameras, 8 “Slaves” and Renderama itself. That’s a tremendous amount of application overhead. I bet renderama and the slaves will eat enough CPU cycles to make 8 Cameras unfeasible, you’d probably only be able to run 7, the eighth would just be supporting all of the renderama apps. You’d probably need another GB of RAM for all of those (although RAM is cheap these days), and just imagine the I/O needs of 8 cameras tugging on all of those render control files at once, and saving out frames and temp files… You may need a heavy duty RAID arrray just to keep up with all of the I/O.
to render full speed with 8 camera, 8 different hard-drives is needed, I guess…
Well, there are different kinds of people. Some of them are “concrete” or “literal”, with a prob they cannot see farther their noses. Others are “strategic” or “generators of ideas”, but, sure, they have their probs too
Paralumino - 08 April 2007 11:12 AM
Multilayers IS the primary focus for EIAS in v7 right now. I’m not debating that. When I talk about focus, I’m talking about focus in relation to the greater subject of MP..not EI’s current course of direction. I don’t think we should completely change what we’re doing now and divert attention away from Multilayers.
There is no any pretension on absolute attention. Simply users should be informed well and objective about what multi-layers feature will do and what will not. Now it’s far away from this.
Paralumino - 08 April 2007 11:12 AM
Users want MP.
Users want ALL
Paralumino - 08 April 2007 11:12 AM
We all know that. But by saying lets “focus” on Rama, I’m suggesting that for the next version (whether v7 or v8) of EIAS we continue to improve the way that program works. The Rama MP solution is acceptible, but clunky. If we streamline the process and provide more features in Rama that not only simplifies the MP task, but also covers deficiencies in the program’s main purpose (distritbuted rendering), users would probably go for that. There are simple things about Rama that could use improvement.
Let’s omit a discussion of technical Rama aspects here. It’s really big and specific. Just there are few considerations from “literal guys”:
- how many time this improvement needs (and how it’s related with vers timeline)?
- what are those improvements essentially?
- how valuable will be effect? Or just “a little better Rama”?
- what other features should be delayed in view of eventual Rama work?
We personally have NO ONE answer (even more or less clear). All that is very and very “blurred”. It’s very possible it will be going into long-long talks/discussions but with zero final result.
Let us say a strange (in first view) thing. We see well: we’ve more and more ideas but less and less concrete results. New and new bunches of interested thoughts are “in focus”, like a butterfly flies from one flower to another. But nothing has an “output” (with that even a butterfly is ahead us). We think: it’s better to have less ideas but more results.
Bare feats has the first 3D rendering test of the MacPro 8 Core.
The Cinebench test shows a 45% performance improvement over the 4 core model using Cinebench (GI render)
Nothing to sneeze at, but still less than 50% improvement for doubling the cores.
This gives some sense of how well renderers can scale with MP.
Other MP apps including Photoshop often showed little or no speed gain at all.
About all this MP polemics.. try to be a bit philosophic (don’t know how to explain better). “Iron race” has no end. How about, say, porting to 64-bits? Also necessary, isn’t it? Then it will be a time for a new OS from Apple (quite in their style). But hey, when to fill a program with new content, new features? There are no companies (even with deep pockets) that do a next porting immediately after previous one. So, there is no any catastrophe, but just news about new Mac 
