About Renderama 2, please support files more than 2Gb when stitching
EIAS 7 Wishlist
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 
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.
Multicore and Mutliprocessor support for animator and CAMERA. for animator… faster write out of animation control files… - bejay - :applause:
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
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
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.
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.
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?
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.
Hi, Dave
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 
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
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.
You are right, Brian. Sorry. Just is one of this days when i miss some power tools, spetialy for character animation.
FelixCat
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! =)
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.
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.
