EIAS 7 Wishlist

#41

Are you saying that Esteve Jobs was lying to us when said that the porting was a matter of half an hour after presing the ¨do convert¨button? Oh tempora, oh mores! we can´t believe nobody…
:smiley:

FelixCat

#42

Hi, Felix

  1. Absolute any porting starts from sentences like “it’s only…” etc.
  2. It’s generally true, but… not for large programs
    For example, a replacing of all textures files in all your prjs is not a big problem, right? :slight_smile:
#43

Do you have USB Overdrive set up to provide scolll support in Animator?

What is your setup?

#44

Firstly, It appears I’m wrong about the X-code thing :wink:

Seccondly, USB override is set up for key combo’s only…

LMB and RMB are normal
LSMB is for copy
RSMB is for paste
Scroll wheel click is for hide/show

EI could fake scroll wheel zooming support by having a key combo for zooming in incrementally (say 1% of distance to reference point).

That way you could set USBO to zoom in and out with the scroll wheel.

I wonder if that is possible?

#45

Zoom in/out should be easy “[” and “]” as simple keystrokes, although it’s a bit too fast.

Let me know If you come up with a way to fake scolling in the project window!
(although dragging the scroll bar is prabably faster)

Scrolling zoom in/out at the mouse pointer (like many other 3d Apps) is a great idea for a new feature.

#46

New feature idea-

A hypergraph view which shows all “nodes” in the project and allows “piping” output from one to an input for another. Basically it could be a graphical control system for expressionist, with icons for the functions, etc.

Personally, I do very well with graphic/ visual control systems, but poorly with text based programming.

#47

We are very poor with graphic/ visual control systems and can do something only in text based programming :slight_smile:

#48

Hi, Ian

Common sense says it’s definitely possible. However, IMO the scenario is not so simple as it’s drawn above. How to organize an effective wheel support for ALL windows? That’s a large piece of work even before any programming implementation is started. A “distance to reference point” - what’s that for isometric view? For Project Window? And, be honest, we think that, say, irradiance maps or area lights or layered rendering would be more needed/wanted now instead of playing with mouse wheel.

#49

Thats great for the perspective views, but as you said, would be great if the camera view had something similar.

And yes Igors, as ever, everything you say is very practical. I’ve never worked with a true events manager so I don’t know how much work it is to change one. You are right about the priority of features, but in my honest opinion the interface in EI does need some more work, for me this is as important as layered rendering or improved area lights.

Ian

Edit: i missed out ‘never’ :slight_smile:

#50

Just a copy of a post at the EITech Group Forum. It seems to fit into this topic.

As of yesterday all new Pro macs are QUAD.
Any possibility of Multithreading Camera, or Animator to split up tasks should be explored, since we are no longer getting most of our performance increases from faster processors, but, rather more processors.

It has been suggested elsewhere that VERTICAL stripes may be more efficient for splitting an image up for MP rendering (due to materials typically rendered for sky and ground planes).

It would be useful for Camera itself to do this striping, and run multiple rendering threads itself (the max # controllable in Camera’s preferences). This would speed up “preview” renders as well as simplify general rendering.

Renderama is great for queing multiple renders, and running a network render farm, but it’s extra overhead eats a lot of processor resources when running on a single machine (Renderama, Slave1, Slave2, Slave3, Slave4, Camera1, Camera2, Camera3, Camera4). That’s a lot of Apps to run in tandem.

Animator may also be able to take advantage of some of this thinking (different threads for redrawing each window, etc.) I am not a programmer, and I am sure these things would be difficult and/or time consuming, but we ARE entering a new era of MP hardware. EIAS has always had exceptional speed, and to obtain new performance levels EIAS should be updated to take maximum advantage of MP hardware.

#51

Its certainly is a reasonable request. Personally, I believe the current method of separating jobs out to different processors through Renderama is important and we should not be quick to dismiss it so easily, however, producing a multithreaded Camera would be nice.

We have two primary programs that we’re using:

Animator & Camera

Multiprocessor support for Camera sounds like it should be first priority over Animator because users want faster previews without having to setup a Rama batch job. The questions would be:

  1. What’s involved in making an application multithreaded?
  2. Can Camera’s architecture support multithreading?
  3. If yes, how much is involved and what would it cost?
  4. If no, can anything be done to change that without a major overhaul of Camera?
  5. How would multithreading be advantageous for Animator?

After the completion of the Intel port, EITG will most likely resume adding new features. Where would you like them to spend their time?

Perhaps someone with more experience with multithreading can share some insights?

#52

I do remember a post by Matt Hoffman on the EITG forums mentioning the difficulties of multithreading Camera. Their attempts failed and they ended up with the solution we’re using at the moment.

#53

Hi, Brian

Here is a seldom case when we agree with you :slight_smile: Yes, we also think that a multithreaded Camera would be nice.

Mutithreading is a parallel code execution in bounds of same process (same address space). It can be implemented with a single processor as well, that’s a problem of OS which processor takes care about which thread. Application is responsible for threads’ initializing, running and killing.

IMO it’s better to ask: Is Camera’s architecture suitable for multithreading? We think that yes, same as any render task. The problem is that multithreading is not a thing can be applied to anything to speed up.

"I’ve 180% speed up with my dual Mac!!!:applause:
"I’ve 115% speed up with my dual Mac :sad:

Both experiments/results are fully true, and percents are not even min/max values. Just a lot depends from what kind of work is processed. Not all can be multithreaded/parallelized. If, for example, you’ve a large MrBlobby in your prj, then most probably it remains same slow no matter how many processors are involved. Cause implicit surface should be built step by step, sequentially, not parallel. That’s true for absolute most geometry generation actions.

However, the shading phase can be parallelized well. It would be especially effective for most RT aspects, count GI. But not for all: building BSP, creating photon maps and some other things should be performed sequentially.

Alas, it’s a very hard work. SDK’s of mutithreaded apps typically gives very short advices, like:

  • compile as mutithreaded DLL
  • avoid to write in static variables
  • that’s absolute enough for your plug-in/shader to be mutithreaded
    That’s true, but only until developer tries to make something not-trivial. And that is only “usage” of host’s pipeline. Difficulties/problems grow tremendously for large app and threads’ “organization”. All memory allocations, writing files and many others should be “surrounded” by semaphores/critical sections. Each thread should be equipped with its own “ray-trace stack”. There are tens and tens problems here

Using more processors is a method of “brute force” (iron instead of brain). Look at RT soft shadows for example. They are poor and slow. One way is to increase a count of samples and add more processors. Another solution is to reorganize the algorithm of shadows calculation. We would like the second way :slight_smile:

We’ve no ideas what could be parallelized in Animator. The preview speed? But it depends more from GPU…

#54

Absolutely. Animator has near instantaneous response for EVERYTHING once the view windows are closed…

The only thing I can think of is Software drawing mode.
Edit: CCN Files? CA’s always complain about them :wink:

As for Camera, I would like to see RT Soft Shadow algorithms ‘massaged’ before ANYTHING else happens with that app :slight_smile:
Ian

#55

As already mentioned, how practical would it be to have previews rendered automatically on 2/ 4 Cameras?

That is to say have a ‘previews’ renderama built into Animator?
So the workflow for the user is the same as now, but 2 Cameras start up and render.
Although, in all seriousness, this would only be practical if Camera could render vertical frame strips, for us, it would be useless otherwise.

Ian

#56

not only CAs! my last project had many, many deformed objects in it. building the control files took around 10min/100frames! even when the deformed objects are turned off.
so, for some utility mask layer renders it looked like this:
writing control files: ~ 30min :scream:
rendering: ~ 10 min

#57

Hi, Ian

Of course, all these things are reasonable, but… they have no any relation with multithreading :slight_smile: Please understand: multithreading is not a “magic” can help for anything isn’t enough fast.

#58

Fair enough, I guess my position is that Multi-threading should not be a priority at the moment. There are other things that should come first.

#59

Hi, Ian

Our opinion is similar (thought very blurred). Other apps have a “bigger material’s ball (or cube, cylinder etc.) with all textures”. IMO it’s still ineffective, a ball is still far away from a real rendered object. Maybe a some kind of simplified render (pre-render) is the best/optimal solution. Not all should be copied :slight_smile:

#60

My work is likely different from others on this forum, so let me elaborate on this subject
As an industrial designer I am producing mainly stills for new products on extremely tight deadlines sometimes only 24 to 48 hrs.

I have many scenes in Animator with many millions of polygons, and often have into the thousands of objects (many, many duplicates) with lots of texture maps.

These projects are unweildy to say the least. Open GL chokes. Even software drawing mode is very slow in outline mode. I am always turning object groups on and off to improve screen redraw.

Rendering for me is pretty fast. I use GI for smaller projects and get render times of 5 to 15 minutes per still (I may produce as many as 30 stills for a project with multiple concepts so as a whole that’s still a lot of render time!). My large projects would take over an hour with GI per still, so I usually fall back on Phong and get good quality in under 5 minutes.

Increasing render speed would be great as I could use more of the “advanced” render features like GI. But slowdowns and workflow in Animator are a legitimate performance bottleneck.

I can appreciate the limits of MP/ Multi-threading, but this is how hardware companies are going to give us more power in the forseeable future. Based on initial 3d benchmarks the latest 3Ghz Xeon from Intel/Apple is roughly equivalent to a 3.2 Ghz G5. Not bad, but that’s only about a 60% performance improvement over my dual 2 Ghz G5 (we’re talking single thread performance) This is WAY off from Moore’s law. Only a 60% performance improvement over a 3 year time frame. However, there are now FOUR of those processors in a single workstation. That’s a lot of untapped potential power.

My point is that the real challenge for software developers is to re-think thier apps, maybe even consider re-writing major parts of them to squeeze every ounce of performance from those extra processors. I understand that much of the calculation in 3D is linear, but being creative with how tasks are divided may yield some good performance improvements.

I will soon get back to the point of this forum with some more practical feature suggestions. Thanks to all for their input. I think this is a great discussion, and I hope Matt, Blair, Igors, and the rest of the EIAS Programming gang are following this and are inspired to make our favorite 3d App better and faster.