PDA

View Full Version : EIAS 7 Wishlist


Vizfizz
01-31-2006, 04:10 PM
I know that Matt Hoffman and the gang at EITG are going to be busy finishing up the last update to 6.5r2 and then the Mactell conversion for a while, but I wanted to open up this thread to EIAS and non EIAS users alike.

What primary features do you wish to see in EIAS 7. (Has a nice ring too it doesn't it? EIAS 7)

Vizfizz
01-31-2006, 06:50 PM
Ok.. don't be shy. Tell yah what, I'll start.

I'd really like to see a nicely implemented referencing system in EIAS 7. No more manual swapping models. Northernlights has given us a nice temp solution with swapper, but I want more. :)

kevmo
01-31-2006, 07:08 PM
Well, since its a wishlist...
I'd like to see true HDRI rendering.
And a UV editor/integration of some sort.

thanx

Vizfizz
01-31-2006, 07:15 PM
Well, since its a wishlist...
I'd like to see true HDRI rendering.
And a UV editor/integration of some sort.

thanx

As much as I agree with you on the UV editing capabilities, I personally don't think you'll see this. Why? If and until EITG starts to integrate modeling capabilities into EIAS, UV editing, in my opinion will remain deligated to the modeling program of choice.

kevmo
01-31-2006, 08:00 PM
yes, and maybe that's not a bad thing...

Maybe an updated Steamroller UV?

well, it is a wishlist!

manuel
01-31-2006, 08:13 PM
-Build in sub-d's. Encage is okay, but it can be a hassle having that plug-in in the middle of a mildly complex rig.

-Redo

-Improved... no wait, make that vastly improved controllers. Especially the rotation-controller. You know, pre-hilighting, decent snap-distance, visualisation of the rotation-angle/drag-distance. The works.

-Settings for picking the length of the motion-path before and after the current frame in keyframes, rather than showing the complete motion-path which can become unwieldy.

-Improved readability of the project-window. I posted a mock-up on the EITG forums (http://www.eitechnologygroup.com/phpBB2/viewtopic.php?t=5660&postdays=0&postorder=asc&start=15) a while ago (about two thirds down)and had a look at it again today. I still believe that the points I made are valid.

-A simple set of modelling tools. Nothing fancy.

richardjoly
01-31-2006, 08:20 PM
For the type of work I do, EI has all the tools I need; but sometimes I would love an Archvision RPC Plugin or similar tool to easily and rapidly enhance my animations.

I dream of a particle system for smoke and fire where I can control coverage, color, intensity, dispersion with all the programming hidden behind the sliders...

Vizfizz
01-31-2006, 08:26 PM
Konkeptoine's Fire offers an interesting solution for fire and smoke.. though there are serious limitations to this plugin.

Dante, PPPro and Fyreworks all have methods of creating interesting flame effects. "Fire" would be a perfect solution if the volumetric solution would deform and follow when animating the fire's source object. Right now, its only practical for stationary flaming objects.

harryb
01-31-2006, 10:32 PM
EIAS is a great package but here is my own personal wishlist for EITG and Animator 7:

-- a streamlined, customizable and much more interactive interface (no more floating palettes everywhere) with a variety of layouts that can be switched out easily.

-- Custom hotkeys!

-- much better cursor-honing for object selection/deselection. Right now selecting and manipulating objects by point-and-click is a hassle.

-- an f-curve editor that behaves more predictably (no more unexpected velocity spikes). Predictable curve flattening with easy-access auto ease-in and ease-out controls.

-- a 3D NLE like Trax in Maya.

-- saveable light and camera presets (drag-and-drop on new light and camera).

-- saveable scene presets complete with world ref maps, lighting and staging.

-- drag-and-drop 3D behaviors (scriptable and editable in Xpressionist) like in Apple's Motion.

-- much better use of mouse controls like a zooming scroll ball (see customizable interface).

-- Quaternion rotation option to minimize gimble lock from current Euller system.

-- vertex manipulation of imported models and more flexible use of sliders for deforming models and making morph targets.

-- a node-based materials editor with instant, accurate material previews.

-- Pre-comped renderpass support for writing layered multipass renderings directly to Shake, Combustion and After Effects.

-- all-in-one RGBAZ files. No more separate .eiz files please.

-- Open EXR support.

-- true HDRI support (see Open EXR support).

-- accurate previews for setting up HDRI domes and spheres.

-- equirectangular file generation option for six-sided environment renderings.

I think that's about it.

WAIT!! Put me down for integrated Rodeo too, partner -- Yeeeeeeee Haaaaaaaw!
I've been waiting for this in EIAS for a long, long time!

Reuben5150
01-31-2006, 11:32 PM
I was halfway though my suggestion when the computer crashed, damit.

Ok, i don't expect all or any of this stuff to make it in v7, and its brobably all been said before, anyway -

1 Polygonal modeling tools, just enough to do the job, no fancy BS.

2 vertex painting, ok yes like a built in Amorphium :)

3 Updated texture editor, lots of little things (if only i could code)

4 Better handling of Zbrush models and UV's

5 Sub-pixel displacement

6 Better asset management, asset browser etc

7 New Imageviewer tools, how about paint and selection tools, support for layers with blend modes, lets make it.. the Electric Image Editor TM :bounce:

8-9-10+ Reserved for EITG eyes only :D


Reuben

percy06
02-01-2006, 12:06 AM
1) i think NLE is not too much to ask for as it will compliment EI realy well

2) maybe licence silo and integrate to more into EI like lightwave. (ask them for like a 10 year contranct where they get pay'd for silo that comes with EI. and you could add the trimmings to glue the 2 apps together.

3) would love the preview for the martial editor hate renders for every little change i make to test it :banghead:

4) build PPP into EI

5) make shaders be able to displace polys if i can alreay, plz tell me how

6) improve radisoity

7) make camara faster and 64bit ready as camera seems to be why people realy love EI

8) camera to render 16bit images

9) add better tutorails to your website or try to get people to update them as they look realy dated.

10) give the website some bling and get the punters in

11) steal users from other apps like truespace give them good competitive xross grades.

the media works adds adds adds. i don't like coke i know coke is bad for me. why do i want it? naff example but point is there.

3DArtZ
02-01-2006, 01:10 AM
I do pre-viz work and a lot of times I supply a reference birds-eye camera view,
then a front, side and top view from the actual front, side and top view windows in Animator.
There are times I'm delivering 15 models or so....
Rendering the camera view is no prob, can send it out to renderama.
But I have to manually render the front, side and top view windows
I'd love to be able to send those windows out to render like the camera window....


Mike Fitz
www.3dartz.com (http://www.3dartz.com)

halfworld
02-01-2006, 06:58 AM
I'll chime in...

1. A tad more optimisation of the RT algorithms...
2. Better texture preview (I know that's a really tough one but that's why it's a wish list) :)
3. Layered 16 or 32bit photoshop output (unless it means re-writing camera... which it does, so ignore that one- wish list).
4. Copy/paste in the proj window name box...
5. Renderama 2! Choose which slaves render what....
6. Sky-light open gl feedback (could even just use the ambient light code(ish)...)
7. Better asset management
8. Throw money at Patrick and get rODEo built in!!!
9. Slow down the Phong render (just kidding).

I think there are a couple of realistic ones there.... 1,4,5,6 are most likely I reckon....

I also want to see scroll wheel support (without USB override), but I think that may come as a side effect of moving to X-Code...

Could, might, maybe,
Ian

SteveW928
02-01-2006, 09:06 AM
1) Like many others said, true update to render-ball. Show real preview of shaders and combinations of shaders along with textures. People say that is hard... is that because Camera is a separate app? Can a 'mini' camera be made to run in the background? I'd think it wouldn't need much resources to just render a simple little sphere and give a true preview.

2) SAT support for model import with render-time tessellation. I'm sure that is a long-shot, but as others have said... it IS a wish-list. Having objects not be tessellated till render-time, and then maybe dependent on how far they are from Camera would be totally cool!

3) A low priority visual update to camera window would be kind of cool too. I know test renders are quick and easy, but often while working on settings and a project... the CPU isn't doing much anyway. If it saved a few test renders, it would be nice.

4) Here is an easy one... a 2nd set of camera settings for preview renders. Basically, currently you have to change your Camera render setting to some lower settings for preview renders, and then change them back to what you want for your final render. It might be nice to have two sets... one for 'Go' and Renderama... and the other that effects preview renders when clicking the icon on the camera window (of course, being to pick either mode from there would be needed).

Thanks,

-Steve

splitpoint
02-01-2006, 02:40 PM
I'll chime in...

5. Renderama 2! Choose which slaves render what....

Ian

I hadn't thought of that but it would be something I could really use.

Put me down for node-based materials as well.

Al

harryb
02-01-2006, 07:57 PM
I'll chime in...

8. Throw money at Patrick and get rODEo built in!!!
9. Slow down the Phong render (just kidding).

Could, might, maybe,
Ian

Rodeo! Where have I been? This is just what I've been waiting for!! I guess I didn't wish big enough.

And yeah, Camera's rendering is just way too fast. ;-)

kevmo
02-01-2006, 08:38 PM
4) Here is an easy one... a 2nd set of camera settings for preview renders. Basically, currently you have to change your Camera render setting to some lower settings for preview renders, and then change them back to what you want for your final render. It might be nice to have two sets... one for 'Go' and Renderama... and the other that effects preview renders when clicking the icon on the camera window (of course, being to pick either mode from there would be needed).

Thanks,

-Steve

or even better (maybe) to be able to Save & or Load settings sets, or with a menu to choose the sets from?

Another wish is for EI to automagically utilize & detect processors.
and in Animator - wouldn't it help with large projects?

thanx

Giacomo_M
02-02-2006, 12:36 AM
>Another wish is for EI to automagically utilize & detect processors.

Yes. My number-one request is to be able to use BOTH processors on a preview render.

GM

plsyvjeucxfw
02-02-2006, 06:15 AM
I'm in favor of:

1) Better Dual Monitor support -- including saving your workspace layouts as named configs.

2) Exporting Models with Displacements Intact -- Displacements are currently render time only but could be used as a modeling technique.

3) Baking out Lighting, Procedural Textures, and Normals to U.V. Maps.

4) Painless Multipass Renders -- Diffuse, Spec, etc. in a format readable by major compositing apps (RLA or OpenEXR).

halfworld
02-02-2006, 09:42 AM
yes a multithreaded Animator and or Camera would be great... that would probably shut us all up for a while :)

cybermode
02-02-2006, 10:47 AM
About Renderama 2, please support files more than 2Gb when stitching

NorthernLights
02-02-2006, 03:41 PM
Boy, you guys don't want much, do you?

kevmo
02-02-2006, 04:05 PM
Boy, you guys don't want much, do you?

I also wish to be a multi-millionaire, or thousandaire...!

;-)

percy06
02-02-2006, 05:43 PM
sounds like a lot of work if you got time in all your rewrites :banghead: could you make a decent hair/fur plugin and maybe cloth physics that would be nice. You be able to start them from scratch :D

Vizfizz
02-02-2006, 05:59 PM
Just a note. In this EITG sponsered forum, we can not speculate on the futures of any particular software, compiler or hardware encryption packages. The transition to Mactel will have its complications, but any particular problems will be examined and solved.

bjoerka
02-02-2006, 07:23 PM
Multicore and Mutliprocessor support for animator and CAMERA. for animator... faster write out of animation control files... - bejay - :applause:

halfworld
02-02-2006, 10:02 PM
Matt has posted a note about the Mactel port over at the EITG forums...

http://www.eitechnologygroup.com/phpBB2/viewtopic.php?t=6116

Now that's what I like to hear :)
Ian

Blur1
02-04-2006, 06:51 PM
I don't know wether these things are possible without throwing out the code base but here's my list.

-Geometry approximation for rendertime subdivision and subpixel displacement (like renderman/mentalray). A nice extra would be a wireframe preview of your subdivision in the openGL viewport (like what encage does, but purely cosmetic).
-Support for 16 bit and floating point (OpenEXR) textures.
-Support for layered PSD files (see C4D/Bodypaint). Great for camera mapping.
-Gamma control that can be used on textures and renders. Currently (to my knowledge) the Gamma control works after the frame is rendered and decimated to 8 bit.
-Floating point output based around OpenEXR frame sequences.
-A baking engine, assuming UV's have come in from your modeling program. Hence, ability to bake shaders, textures (any projection type), GI etc.
-Multiprocessor/multicore support for preview renders. Tied in with renderama for a kind of grid computing thing would be good (like AE Gridiron rendering or mentalray satellite rendering). This could in theory yield incredibly high quality ipr.
-Modern render pass system that supports AOV-style render output, ie. all passes output simultaneously to subdirectories, or optionally, a multichannel OpenEXR file. Custom user created passes. The Maya 7 render pass system looks really good and extensive and is perhaps a good reference for a possible EIAS implementation
-Bent normals and Ambient Occlusion shaders (bakeable to UV's with the baking engine). -Ability to do environment lookup with bent normals data (as a GI alternative).
-Ability to output frame sequences reliably (apologies if that is already possible).
-Camera.temp files (or do I mean animation control files? I forget), "make sure" that writing them does not cancel out the speed advantage of Camera. If they crash, make them recoverable where they left off. ie. deformations scan slow them to a crawl.
-Camera preview renders tabbed together
-Alternative render settings for preview renders

Other:

-Definitely layered texture previews in OpenGL, better shader previews.
-Non-modal shaders/plug-in dialogue boxes (this is happening now I think)
-Custom UI layouts saved as instantly recallable presets.
-Move texturing into the viewport?? Less windows to deal with.
-Mousedrag to adjust values dynamically

marosini
07-31-2006, 10:15 AM
maybe too many wishes around...

If I could send a letter to Santa Matt for the MacTel rewriting holydays I would ask multipass rendering and EXR save (with z and alpha, of course) but I guess it's way too radical in the short term.

m.

marosini
07-31-2006, 10:42 AM
maybe too many wishes around...

If I could send a letter to Santa Matt for the MacTel rewriting holydays I would ask multipass rendering and EXR save (with z and alpha, of course) but I guess it's way too radical in the short term.

m.

NorthernLights
07-31-2006, 03:59 PM
EITG will make a deal with you: You all go forth and get 1000-2000 new EI customers and they'll start adding major features. Sound good?

arketype
07-31-2006, 09:18 PM
Based on the discussion on this forum from the very active plugin developers it seems they are often limited in what they can accomplish , so...

How about a new Plugin API so that plugins have greater freedom for interaction. Perhaps this would necessitate interaction in the worldspace. This would also allow for updated versions of modeling plugins to have interactive controls in the project window, instead of needing to go into the "plugin" space" to edit, etc.

This would take pressure off of EITG to get modeling into EIAS, as robust modeling features could be added by 3rd parties, and function as if they were "native".
This would also allow EITG to focus mainly on Camera rendering technology, and file format support. (heck, why can't there be plugins to support file formats?). EITG could just open up EIAS to all sorts of good stuff with this one major "super plugin" feature.

It would be great for the developers to chime in on this and see where the current plugin limitations reside.

Igors
07-31-2006, 10:00 PM
Hi, DaveHow about a new Plugin API so that plugins have greater freedom for interaction. Of course, such API would be great, but chances to have it in near future are below zero. Nevertheless, we like how your minds are flowing :)

Vizfizz
07-31-2006, 11:06 PM
True... the intel port is first in the order of priority by a light year.

FelixCat
08-01-2006, 12:36 AM
I agree absolutely with everithing said... all the wishlist sounds great. But, as Brian says ¨the intel port is first in the order of priority by a light year¨
Sadly, that let us far, far behind the crowd.

FelixCat

Vizfizz
08-01-2006, 01:18 AM
I only meant a light year between getting the port finished to having a bunch of new features. Its one or the other and the port must be first in priority. Any new features in PowerPC code would be a waste of time.

Even if we are the last 3D application to port, I don't think we're light years behind other products. (Maybe a couple of A.U.s, but certainly not light years). Third party teams are helping to close the gap. Besides, there aren't any pro/tower intel macs available yet....so there ya go.

FelixCat
08-01-2006, 02:47 AM
You are right, Brian. Sorry. Just is one of this days when i miss some power tools, spetialy for character animation.

FelixCat

sacslacker
08-01-2006, 10:25 AM
I'd say if you're going to look at a good multipass system, take XSI's functionality over Maya's. Maya is way behind XSI in that respect (I'm sorry to say). I use ctrl_buffers in Maya for passes.

I've recently had to work with XSI on a project and holy cow, I'm impressed. Avid has done a very nice job on that application. Very nice indeed. However, it still doesn't have camera so... pfffft! =)

NorthernLights
08-01-2006, 04:06 PM
A MacTel port is not a trivial thing (i.e. "Whaddya mean it's not JUST a recompile?!?"). In the first place, EI isn't one application, it's really three or five if you count ImagePlayer and Transporter. Each one of these must be turned in to a Mach-O app, brought over to XCode, cleaned up because the GCC compiler is very finicky, recompiled, relinked, all external libraries such as FBX and Shockwave need to be updated assuming that their respective developers have kept up with things, etc. etc.

And then there are plugins and shaders. Currently plugins and shaders are built in CFM/PEF format. CFM/PEF is deprecated at best. At worst, these would all have to be converted to dynamic libraries. Yes there are ways to call CFM from Mach-O but how well that works is a question. And all that stuff that needed to be done for the apps needs to be done for all plugins and shaders.

And once all this is done, everything needs to be compiled for the Intel processor and everything needs to be retested because of the endian issue.

Of course this isn't completely nasty because you can avoid all the pitfalls you ran into with the first conversion on subsequent conversions.

IMHO the biggest pain is XCode itself. It's not nearly as clean and forgiving as Codewarrior and doesn't lend itself well to large projects. IMHO, the commentary from Adobe on the subject is right on target.

But just when you thought things are gloomy, consider this: rumor has it that Maya 8 hasn't been compiled for native MacTel. So if all goes well, EI might have yet another edge over Maya at least for a while.

manuel
08-01-2006, 04:50 PM
Isn't XCode the direct descendant of the Nextstep developer tools? I thought quite a few developers used Nextstep just because it was so much easier to develop in that environment. I'm not questioning your judgement by the way, just surprised to hear that XCode is such a downer for you guys.

FelixCat
08-01-2006, 05:02 PM
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...
:D

FelixCat

Igors
08-01-2006, 09:21 PM
Hi, FelixAre 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...
:D

FelixCat1. 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? :)

arketype
08-03-2006, 08:59 PM
I'll chime in...


I also want to see scroll wheel support (without USB override), but I think that may come as a side effect of moving to X-Code...

Ian


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

What is your setup?

halfworld
08-03-2006, 09:08 PM
Firstly, It appears I'm wrong about the X-code thing ;)

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?

arketype
08-03-2006, 09:35 PM
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.

arketype
08-03-2006, 09:40 PM
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.

Igors
08-03-2006, 09:51 PM
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.We are very poor with graphic/ visual control systems and can do something only in text based programming :)

Igors
08-03-2006, 10:14 PM
Hi, IanFirstly, It appears I'm wrong about the X-code thing ;)

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?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.

halfworld
08-03-2006, 10:24 PM
Zoom in/out should be easy "[" and "]" as simple keystrokes, although it's a bit too fast.

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' :)

arketype
08-08-2006, 05:27 PM
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.

Vizfizz
08-08-2006, 11:32 PM
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?

manuel
08-09-2006, 12:02 AM
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.

Igors
08-09-2006, 02:10 AM
Hi, BrianIts 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.Here is a seldom case when we agree with you :) Yes, we also think that a multithreaded Camera would be nice.

1. What's involved in making an application multithreaded? 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.

2. Can Camera's architecture support multithreading? 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.

3. If yes, how much is involved and what would it cost?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

4. If no, can anything be done to change that without a major overhaul of Camera?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 :)

5. How would multithreading be advantageous for Animator? We've no ideas what could be parallelized in Animator. The preview speed? But it depends more from GPU..

halfworld
08-09-2006, 08:03 AM
We've no ideas what could be parallelized in Animator. The preview speed? But it depends more from GPU..

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 ;)

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

halfworld
08-09-2006, 08:09 AM
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

bronco
08-09-2006, 10:18 AM
Edit: CCN Files? CA's always complain about them ;)
Ian

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

Igors
08-09-2006, 11:37 AM
Hi, IanAbsolutely. 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 ;)
how practical would it be to have previews rendered automatically on 2/ 4 Cameras?Of course, all these things are reasonable, but.. they have no any relation with multithreading :) Please understand: multithreading is not a "magic" can help for anything isn't enough fast.

halfworld
08-09-2006, 12:28 PM
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.

Igors
08-09-2006, 02:11 PM
Hi, IanThat is to say have a 'previews' renderama built into Animator?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 :)

arketype
08-09-2006, 02:17 PM
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.

arketype
08-09-2006, 02:23 PM
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.

halfworld
08-09-2006, 02:48 PM
Hi, IanOur 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 :)

By preview I was meaning 'Snapshot'. However you bring up an interesting subject! I am very much in favour of this kind of feature.

But by pre-render do you mean a no frills snapshot? Perhaps add a render option to the linking editor 3d view? Then you could render one group at a time with no frills...

Thinking out loud,
Ian

Martin Kay
08-09-2006, 03:47 PM
Well, I'd like to see better material previews. A more consistent numerical data input. More feed back during rendering. I'd like to see the product marketed- no-one knows about it. This isn't healthy.

Martin K

Igors
08-09-2006, 05:08 PM
Hi, IanBy preview I was meaning 'Snapshot'. However you bring up an interesting subject! I am very much in favour of this kind of feature.
But by pre-render do you mean a no frills snapshot? Perhaps add a render option to the linking editor 3d view? Then you could render one group at a time with no frills...

Thinking out loud,
IanWe too :) We heard many times about "better material preview", but what is it? No one knows and no one app has an ideal preview. What we do now to setup material? Something like: edit - snapshot - edit - snapshot.. many times. Often it needs to simplify scene: turns off other objects, lights, set additional cameras etc.

It would be nice if host does this routine work for us. For example: we are in Texture Window, press F7(?) and let host runs Camera with actual object only, simplified preview lights and actual orbit view. Add some "variants", for example:
- render a whole material;
- render actual texture only;
- render textures stack up to actual one

Another one: re-render a selected/desired object only in previous screenshot screen. Yes, it will have a jagged edges etc. - that's only a draft sketch. But IMO it shows enough well how material looks in scene.

And who knows, maybe this set of modest features would give much more than a "super" preview promises "real-time" but ends with 50K of polys. Or with fractal noise with 5 and more octaves. Or with many other things.

halfworld
08-09-2006, 05:29 PM
Hi, Igors,

That is actually exactly what I was thinking off! :)
Ian

MagicEgger
08-09-2006, 08:16 PM
Ola,

One of the best ways I think its the way to preview I think Its Fprime:
http://www.worley.com/fprime.html
or L-Pics from Pixar
http://www.vidimce.org/publications/lpics/

If we could have a window (the snapshot preview window) be feeded by camera caches in a loop in the background without camera window lauching.. without anti-aliases and using the best of all MP processors we could have a interesting and almost realtime preview.


Tomas Egger

juanxer
08-11-2006, 09:34 AM
What's the reason Renderama has that big an impact in local multicamera rendering? The fact that it treats local cameras as networked ones? Or is it just slow managing things?

If producing a multithreaded Camera is so complicated, perhaps it would be better to create sort of an specialized Renderama-like app, say, "MetaCamera", able to talk more directly to several local Camera copies and do tricks such as dividing the frame into four stripes (would that route produce less overhead than assigning different frames to each pooled Camera? Would it be faster for Renderama to address several networked MetaCameras, each networked PC producing single frames instead of fours by using the striping technique?), or knowing when there is a pending preview job and having some preference for resolving it even if it is in the middle of an animation job (assigning one Camera to it, or pausing the main job to dedicate all Cameras to it)...

For a striped image task division technique, perhaps MetaCamera could be smart enough to try pre-ordering things like precalculated shadows and cubic reflections so that they can be shared among the pooled Cameras: even if they have to wait at idle for one of them to build these, in the end a MetaCamera would be faster than every Camera doing it itself, I guess.

Igors
08-11-2006, 06:19 PM
Hi, JuanxerIf producing a multithreaded Camera is so complicated, perhaps it would be better ..All is not very complicated was done in previous 10-15 years :) LOL
Yes, multithreaded render is hard to implement but same time it promises effective/attractive results. If Tomas and Jens run a serious RT/GI scene on their quads and have got x3 and more speed up - they can say only "wow" :) Multithreaded technique does not "duplicate" memory allocation same as models', plug-ins' and shaders' loading for each render instance. The discussion sorta "what's better: MP or network render" is obsolete IMO - now it's time when 3d app should have both

arketype
08-11-2006, 11:10 PM
I Agree Igors!
Well Said.

arketype
08-15-2006, 02:05 PM
Interesting note about rumored multi-threaded OpenGl for OSX.

I don't know the limitations of this, or if graphics cards more of a bottleneck, but it is rumored to have significant impact for games.

Perhaps this could bode well for increased redraw performance for Animator?

http://www.insidemacgames.com/features/tuncersblog.php?ID=106

kevmo
08-25-2006, 05:13 PM
What I wish for is an integrated sub-D modeling - maybe Silo/Nevercenter & EIAS should partner and that would also create many more users for both sides.
If not EI should make their own - I think this may be one of the reasons that potential new users may pass it by.
But even still it is a pain to go back and forth between apps as it stands.

Vizfizz
08-25-2006, 05:32 PM
Ok..shameless plug here...Paralumino's geometry series of plugins allow base level, internal modeling capabilities to EIAS that really make life easier. Combined with Konkeptoine's Encage and you have the foundation for what you're looking for. Is it as powerful as a dedicated modeler? Alas, no. We admit that its not. However, we are constantly working to add new modeling tools. We have 3 more in the pipeline and plans to upgrade Trestle in the future.

Of course I'm being biased here, but now that I can generate geometry within EI, I'd have little need to go to an external program unless the shape is highly organic or has sophisticated modeling requirements.

kevmo
08-25-2006, 05:54 PM
Yes, I'm aware of the plugs and I think it is a great solution for some things...and good luck with your new site/services BTW.

As much as I loved/hated EIM, it probably didn't have much of a future anyway.
I really like Sub-D modeling and it seems to becomeing a standard modeler in many, many apps.
Some packages have many different flavors of Sub-D tools and it can be really easy and fun to work with and yes it can also be a challenge depending on what you are trying to accomplish.

But anyway, like you stated, I'm looking for a level of control and integration with EI.

but this is a wishlist...?

thanx
k!

AzOne
08-25-2006, 05:59 PM
I'm not a technical person, so I'm completely in the dark about what goes into the GI implementation in EIAS. What I do know - and I'm simplifying here :-) - is that:
-it makes my pictures look better
-it's relatively easy to use
-it doesn't take forever to render
-I use GI in almost all my work since upgrading to v6.5

but there is that noise in animation issue which (I learnt from another thread) is part and parcel of GI. Yup, I'm aware of ways to minimise it. But, looking at the PIXAR presentation here:

http://graphics.pixar.com/index.html

under the topic 'Statistical Acceleration for Animated Global Illumination', I wonder if EIAS 7.0 (or later) could implement PIXAR's solution to the noise issue. Or is a similar solution already being implemented in EIAS 6.5's GI? Am I completely misunderstanding the PIXAR video presentation on the topic?

Igors
08-25-2006, 07:04 PM
Hi, Azizbut there is that noise in animation issue which (I learnt from another thread) is part and parcel of GI. Yup, I'm aware of ways to minimise it. But, looking at the PIXAR presentation here:

http://graphics.pixar.com/index.html

under the topic 'Statistical Acceleration for Animated Global Illumination', I wonder if EIAS 7.0 (or later) could implement PIXAR's solution to the noise issue. Or is a similar solution already being implemented in EIAS 6.5's GI? Am I completely misunderstanding the PIXAR video presentation on the topic?We aren't familiar with pdf this link points to , so, sorry if our considerations are superficial a bit. But from the description we've read the situation looks very typical.

"The resulting animation has greatly reduced spatial and temporal noise, and a computational cost roughly equivalent to the noisy, low sample computation"

Aha, clear, less noise in animation and great speed. We've no any foundation to say it's not so. However, look for what is a cause of these improvements, or, in other words, what this technique is based on:

"We begin by computing a quick but noisy solution using a small number of sample rays at each sample location. The variation of these noisy solutions over time is then used to create a smooth basis. Finally, the noisy solutions are projected onto the smooth basis to produce the final solution."

In practice and in simple words it means: this technique assumes a series of frames is in use("over time"). Thus we cannot hope for speed up/benefits if we've not a "database of pre-rendered frames". Thus we've a guaranteed bunch of problems sorta "how to sync database if something is changed in scene besides camera motion".

Generally, the idea "to use data of previous/next frames" is very popular in theory, but..not in practice :) Yes, great improvements, but.. too complex and (more important) too unsafe for user

Igors
08-25-2006, 07:20 PM
As much as I loved/hated EIM, it probably didn't have much of a future anyway.
I really like Sub-D modeling and it seems to becomeing a standard modeler in many, many apps.
Some packages have many different flavors of Sub-D tools and it can be really easy and fun to work with Ah ha, clear, "modeler = extruding vertices + Sub-D". Animated statues etc. We think it's not a whole modeler yet, and, maybe, not even its main part. Brian is absolute right with his sentence "COMPLETE set of modeling tools". BTW: interactive vertices operations are also planned.

threedeworks
09-01-2006, 07:46 PM
Ola,

One of the best ways I think its the way to preview I think Its Fprime:
http://www.worley.com/fprime.html
or L-Pics from Pixar
http://www.vidimce.org/publications/lpics/

If we could have a window (the snapshot preview window) be feeded by camera caches in a loop in the background without camera window lauching.. without anti-aliases and using the best of all MP processors we could have a interesting and almost realtime preview.


Tomas Egger

tomas, i agree completely, btw. fprime changed my workflow completely and is one of the first reasons for me to use more and more lightwave for complex texturing/ lighting tasks (especially for interior perspectives).

the reason is simple. the preview and tweak cycle to get a complex viz project done is quite slow on EIAS. this is partly due to the missing material previews, but also because camera is not multithreaded, thus not using the full power of a quad processing unit for all the hundreds of small preview renders a complex project involves. after all, at least if you are doing architectural stills, the scene setup time (including lighting and texturing) is the most time consuming part of the image creation process. even the fastest camera rendering speed cannot compensate for a lengthy scene setup process. in my experience the scene setup time takes more than 3 times the rendering time (but this depends, of course how fast you are, what hardware you are using, etc..). anyway, there is a lot of potential for improvements in this area, imho.

of course, if you are doing animations, the sheer rendering speed of camera has again much more weight and makes those points appear less important!

i hope very much that the next version of EIAS may include some sort of improvement in this area - a sort of 'instant' raytrace/ GI preview tool like fprime would be THE killer feature for us viz guys :)

cheers

markus

Reuben5150
09-11-2006, 07:41 PM
A few more things -

I'd like to see the handling of large texture and image files improved, in particular, HDRI's.

On the PC a 50-55mb HDR into Imageviewer the loading time is very slow and often will crash the app (its been some time since i tried this though) loading a Light gel is slow also.

Loading of large texture maps can be slow depending on size.

So my suggestion is that wherever we are waiting for a preview to be calculated, ie, in the light gel tab or the texture editor window, why not have a cut-off point (file size) at which a texture or image preview would not be automatically calculated, instead maybe a message displayed like "large image - click to preview" then the preview activated at the user wish.

The other thing is Transporter,

i'm still unhappy with the handling of Zbrush .OBJ's, large files crash the app, and the ones that do come though have the texture alignment polygon triangulated, in other words, uv mapped models never come though as 100% quads.

Also, Transporter always seems to be "recomputing vertex normals" whether the "process vertex normals" checkbox is selected or not, i thought it might be the same thing.. maybe not, but anyway it would be nice to have the option of turning off the "recomputing vertex normals" thing cause it slows down the loading quite a bit.

Reuben

AVTPro
09-12-2006, 02:39 AM
EI Wish List

Being that EI's greatest strength is rendering and easy of use I propose we take a solid stand in separating ourselves above the crowd in the area of Zbrush Rendering for animation. I believe it's apparent by now, with Pirates of the Carribean, and WETA MudBox, ZBrush 2.5D modeling and painting paradigm is HUGE! The real deal. Tops. The shiznizzle! We should focus on it and EI become a smart, fast, easy and doable tool to render and mildly animate large ZBrush scenes with humongous polycounts. Thats what EI does well already anyhow.

This is my first request.

ZTool importer.

1. Steamline the ZBrush "imports" to where it's perfect, easy handling, better and unlike any app currently using ZB. This would be a "new" approach beyond what it's already capable of. Literaly pull the Ztool import engine out of Zbrush. Zscripts or licensing. however or whatever it take to acheive this level of perfection. Best case scenario would be to simply import as Ztool directly into EI. No other app, save ZBrush does this so I don't know how intense or challenging this would be. Undoubtably, Zbrush's Ztools imports with the maps and high/low subdiv proxy as "adjustable" depth and RENDERs. That's the perfect process. They do it. That ZTool type import mechanism would be the goose that lays golden egges for EIAS as a Hollywood film render.

EI would be completely unique as a Zbrush Render app if they had access to Pixologic's "Magic Zbrush" button. "Load Ztool". No placement or adjustment of textures whatsoever unless so desired. Just import the Ztool and pick your subdiv resolution, RENDER.

Geometry could be either Encage or EIAS supports an UBERNURB subdivision geometry. I suspect an import with Encage and the Subdiv tool to be more practical and resourceful than EITG writing another geometry type than polgons. Automate this process to feed into Encage if not their own non-ACIS uber nurbs with out linking. Maybe Palumino can do all this.

Texture would be like a Fact File with associated textures. They just go in the right window, with UV checked. No placement or editing. No setting up rotation (-180).
Maybe it can have an import box like FBX where this happens once and is saved as a preset. EI would read each map file type (bmp,psd, etc.) as Zbrush exports it. (color maps, disp, normals). What ever was the last settings/resolutions that it what EI would refernce and import.

So 64 bit images, or was it 32 bit depth? Zero midpoint gray and would all have to be suported in EI. We know how to do this manually, why should we redo it everytime on a computer? I think we should nail like we NAILED FBX!!.

I just bartered a new MacPro from a ZBrush/FBX/Maya work...Bring it!!

I'm ready. Let's do it.

CGTalk Moderation
09-12-2006, 02:39 AM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.