Re: RealLens 2
# You mean this old chestnut?
def dispFix( badDispatch ):
import win32com.client.dynamic
# Re-Wraps a bad dispatch into a working one:
return win32com.client.dynamic.Dispatch(badDispatch)
# Ah... the one thing I won't miss about Softimage.
On Mon, Jul 14, 2014 at 2:52 PM, Francois Lord flordli...@gmail.com wrote:
We've always been patching our installs because of all the legacy code we
have.
I don't even know how to code for the unpatched version!
On 14-Jul-14 17:45, Steven Caron wrote:
personally, i have stopped patching python installs and just re wrap it as
i need it and/or use methods which i know are more stable...
On Mon, Jul 14, 2014 at 2:40 PM, Francois Lord flordli...@gmail.com
wrote:
H... right.
(Like most people) You're using the python that comes with Softimage, the
one that's not patched for dynamic dispatch.
I didn't think of that. I'll have to dive deep and fix this then.
Oh well, to be continued.
On 14-Jul-14 17:01, Tim Crowson wrote:
Thanks Francois, but perhaps I've installed it incorrectly... I get the
camera primitive, but I get the following errors... I installed it via
'Install Addon...' and restarted Soft 2014 SP2, and I just get this:
*# ERROR : Traceback (most recent call last):*
*# File Script Block 2, line 97, in RealLens2Prop_DefineLayout*
*# oLayout.clear()*
*# File C:\Program Files\Autodesk\Softimage 2014
SP2\Application\python\Lib\site-packages\win32com\client\__init__.py, line
465, in __getattr__*
*# raise AttributeError('%s' object has no attribute '%s' %
(repr(self), attr))*
*# AttributeError: 'win32com.gen_py.Softimage|XSI Object Model Library
v1.5.PPGLayout instance at 0x545390152' object has no attribute 'clear'*
*# - [line 96 in
\\fs1\g\_WORKGROUPS\softimage\2014\Addons\RealLens2\Application\Plugins\RealLens2.py]*
*# ERROR : Traceback (most recent call last):*
*# File Script Block 2, line 97, in RealLens2Prop_DefineLayout*
*# oLayout.clear()*
*# File C:\Program Files\Autodesk\Softimage 2014
SP2\Application\python\Lib\site-packages\win32com\client\__init__.py, line
465, in __getattr__*
*# raise AttributeError('%s' object has no attribute '%s' %
(repr(self), attr))*
*# AttributeError: 'win32com.gen_py.Softimage|XSI Object Model Library
v1.5.PPGLayout instance at 0x544332680' object has no attribute 'clear'*
*# - [line 96 in
\\fs1\g\_WORKGROUPS\softimage\2014\Addons\RealLens2\Application\Plugins\RealLens2.py]*
*# ERROR : Traceback (most recent call last):*
*# File Script Block 2, line 284, in ApplyRealLens2_Execute*
*# oCProp = oCamera.AddProperty( RealLens2Prop, False, RealLens )*
*# File COMObject unknown, line 3, in AddProperty*
*# File C:\Program Files\Autodesk\Softimage 2014
SP2\Application\python\Lib\site-packages\win32com\client\dynamic.py, line
276, in _ApplyTypes_*
*# result = self._oleobj_.InvokeTypes(*(dispid, LCID, wFlags,
retType, argTypes) + args)*
*# COM Error: OLE error 0x80020101 - [line 283 in
\\fs1\g\_WORKGROUPS\softimage\2014\Addons\RealLens2\Application\Plugins\RealLens2.py]*
*# ERROR : OLE error 0x80020101*
*Application.ApplyRealLens2()*
-Tim
On 7/14/2014 3:41 PM, Francois Lord wrote:
Hi List.
I finally updated my old plugin RealLens, 9 years later (!).
It now creates a camera rig, applies the plugin on the camera and stays
live on the camera.
https://s3.amazonaws.com/public.francoislord.com/RealLens2.1.xsiaddon
Get - Primitive - Camera - RealLens2
We've been using it in production here at Oblique since Febuary. It seems
to work fine. If you find any bugs or have any comments, feel free to ping
me.
Cheers.
Francois
--
Re: Any recommended tutorials/training on building Maya plugins in Python?
You can pass a string command to maya.utils.executeDeferred like this:
maya.utils.executeDeferred(allIWantToDoIsBuildAMenu('FFS'))
I guess that will run your code when Maya finally goes idle or something.
There may also be some trickery you can do that will force Maya to
evaluate the main menu early.
Just don't try to parent a menu to 'renderView' because apparently that
never exists, and when it does, it's volatile. So maybe you could do it
with some kind of callback... I think maybe it's the same for other
volatile windows, but I haven't really tried.
http://help.autodesk.com/cloudhelp/2015/ENU/Maya-Tech-Docs/CommandsPython/callbacks.html
Apparently there's a callback specifically for adding render passes to the
render view menu, but not for adding menu items to it in general? Very
odd. The Maya callbacks kind of seem like a random assortment of hooks
asked for by various studios at various times.
Best of luck!
On Thu, Apr 17, 2014 at 6:30 AM, Tim Crowson tim.crow...@magneticdreams.com
wrote:
And no this isn't the only place I'm asking this :-)
I'm getting into the Maya API and I need to port some of our tools over
from Soft. Google gives me all kinds of interesting links, but I'm curious
to know from people here who have done dev work for both Soft and Maya
(there's so many of you, I know right?) if you can recommend resources for
learning how to create a proper Python-based plugin in Maya. Basically,
what's the equivalent to the XSI Addon or the self-installing plugin? Stuff
like that. I think I can figure out the deployment side of things. I'm just
wondering what's required for a Python plugin to be a python plugin in
Maya. Would be nice to have *Ye Olde SDK Wizarde* around
And on another note
I know this isn't a Maya list but since I'm here and you've read this
far... here's something on the weird chance you might know... I've been
messing around in Maya 2015 with my userSetup.py to have a custom menu pop
up in the menu bar at launch. But the userSetup.py file seems get run *prior
to* the Maya Window being initialized, so it fails to add my menu because
it can't get the main window to which it needs to add the menu. The main
window is simply returned as a NoneType object. The function looks
something like this...
*def buildMenu():*
*ptr = mui.MQtUtil.mainWindow() # at launch this returns None*
*? **mayaWindow = shiboken.wrapInstance(long(ptr), QtGui.QWidget)*
*mainMenu = cmds.menu('MyMenu', p=mayaWindow, l='My Menu')*
*cmds.menuItem(p=mainMenu, d=True, dl='Some Divider')*
*cmds.menuItem(p=mainMenu, l='Some Tool')*
The error comes from *wrapInstance(long(ptr))*, because ptr is being
returned as *None*.
Anyway, on the off-chance...
--
*Tim Crowson **Lead CG Artist*
*Magnetic Dreams, Inc. *2525 Lebanon Pike, Bldg C, Suite 101, Nashville,
TN 37214
*Ph* 615.885.6801 | *Fax* 615.889.4768 | www.magneticdreams.com
tim.crow...@magneticdreams.com
HQV Causing Major Slowness with File Save and Reference Model Updates
*FOR IMMEDIATE RELEASE* *April 15, 2014* *SOFTIMAGE QUALITYBLEED VULNERABILITY* Discovered by Security Researchers Gibli, Barosin, Pancres, Friedman, Akita, Jones, Panisset, Barbieri and Piparo Psyop experienced a Eureka moment today, when an artist discovered that updating referenced models was nearly two orders of magnitude faster when done through RDP (remote desktop protocol) rather than on a local workstation. Simultaneously, a different artist in LA encountered issues with slowness saving files in Softimage, and a quick test confirmed that saving the scene via RDP was also two orders of magnitude faster. This led to a flurry of troubleshooting, and we have since narrowed the problem down to Softimage's High Quality Viewport feature. The speed-ups after disabling HQV are nothing short of mind-blowing. For example, unloading a referenced model took 250 seconds before the fix, and only 3 seconds after the fix. Meanwhile, a scene that took 15 minutes to save saved in only 30 seconds after the fix was deployed. One artist's wife was quoted as saying, Thanks to the Qualitybleed bug being fixed, my husband finally comes home from work on time! Now if I can just get him to stop spending all his free time watching Houdini tutorials... Note that the high quality viewport preference that causes the problem is *enabled by default*, Psyop doesn't generally use HQV in our scenes, *so people are likely to be affected by this problem whether they are HQV users or not*. To fix the problem, affected softimage users can run the following Python command: Application.SetValue(preferences.Display.high_quality_viewport, False, ) There is still much research to be done to find out what kinds of scenes/models are more susceptible to the problem, but we thought we'd bring it up now in case it's costing others time. Given that the problem was tied in with RDP, it's likely that video drivers could be playing a role, but so far we weren't able to find any settings that would magically eliminate the problem without just disabling HQV entirely. Psyop is on a mix of NVidia Quadros and we ran tests with a few different drivers, including the recommended ones. We also saw the same problem across two different workstation images, in both Softimage 2013 and Softimage 2014, and on a remote worker's home workstation. So we have reason to suspect it's not a highly specific aspect of our configuration that was causing the problem. No testing has been done yet on Linux. We will be sure to keep this list updated as more information becomes available. Share your stories in the comments below if you have been affected by this ~100X slowdown in performance, or if you encounter a workstation that is somehow unaffected.
Re: Sort Controller - Open Source Release!
I'm very biased of course, but I have to say I'm a huge fan of this tool :) Thanks for putting the release together, Jonah! On Thu, Apr 3, 2014 at 6:03 PM, Ognjen Vukovic ognj...@gmail.com wrote: Thank you so much, this is an amazing tool. On Fri, Apr 4, 2014 at 2:53 AM, Jason S jasonsta...@gmail.com wrote: On 04/03/14 20:10, Jonah Friedman wrote: So if geometry is added to your characters, or more characters were added, your passes can be kept up to date by keeping the sort groups in the assets up to date. Overall though, it's very simple to use and none of our lighters has had any problems picking it up. The Sort Controller allows a lot of different workflows and these can be as simple or complicated as they need to be, and it's not an all or nothing proposition. It works on jobs of all sizes and has served us well for many years. Man.. can't count how many times this would have been invaluable.. Thank you! On 04/03/14 20:10, Jonah Friedman wrote: By adding a layer of proceduralism to passes and partitions, the Sort Controller puts Softimage passes another five years ahead of... well.. never mind! That would come to ~..17 ..and counting
Re: LUTs in region render clipping
Some thoughts/guesses: From the command line you posted, it seems like the lut you have is trying to go from linear to your viewing space, correct? Is it possible your issues are stemming from a) linear luts coming from linear space generally only get applied to the data between 0 and 1 (because, where do you stop?) b) it takes a lot of values to encode linear space linearly, and you may be seeing significant quantization. The difference between the lut in xsi and in nuke could possibly be due to different interpolation modes between the two programs. Maybe Nuke is doing a better job approximating a curved response between data points in the lut? I'm just speculating. I'm not sure why the lut would look overexposed in xsi. Maybe it's the same quantization thing as b? Can you confirm what colorspaces the original 3dl is mapping between? On Mon, Mar 24, 2014 at 12:16 PM, Simon van de Lagemaat si...@theembassyvfx.com wrote: Here's what my comp guy is saying. Seems like most people who have success aren't converting their luts but instead are creating them from scratch. We're converting a 3dl lut with ociobakelut We're using ociobakelut with config-free baking. We want to convert it to a .csp file to use in XSI current command is ociobakelut --lut lut.3dl --format cinespace lut.csp However when we load the lut.csp into soft without pre-conditioning we don't get a match? Colour kinda looks ballpark but it looks over exposed Loading the .csp back into nuke and it matches with the .3dl ? On Mon, Mar 24, 2014 at 10:52 AM, Andy Jones andy.jo...@gmail.com wrote: Maybe you need to add a shaperspace? ociobakelut.exe --iconfig ocio_config_path --format cinespace --inputspace inputspace shaperspace lg10 --outputspace outputspace --looks looks output_path On Mon, Mar 24, 2014 at 8:58 AM, Simon van de Lagemaat si...@theembassyvfx.com wrote: 2013 w the sp On Monday, March 24, 2014, Jens Lindgren jens.lindgren@gmail.com wrote: What version of Softimage are you using? /Jens On Sat, Mar 22, 2014 at 12:11 AM, Simon van de Lagemaat si...@theembassyvfx.com wrote: Trying to get a show lut going in the region render and we're getting consistent clipping in the highlights no matter what type of lut (csp and cube) we try and no amount of preconditioning is helping... is this just a case of the region render not being fp? Is there a possible fix for this I'm not aware of? -- Jens Lindgren -- Lead Technical Director Magoo 3D Studios http://www.magoo3dstudios.com/
Re: LUTs in region render clipping
Maybe you need to add a shaperspace? ociobakelut.exe --iconfig ocio_config_path --format cinespace --inputspace inputspace shaperspace lg10 --outputspace outputspace --looks looks output_path On Mon, Mar 24, 2014 at 8:58 AM, Simon van de Lagemaat si...@theembassyvfx.com wrote: 2013 w the sp On Monday, March 24, 2014, Jens Lindgren jens.lindgren@gmail.com wrote: What version of Softimage are you using? /Jens On Sat, Mar 22, 2014 at 12:11 AM, Simon van de Lagemaat si...@theembassyvfx.com wrote: Trying to get a show lut going in the region render and we're getting consistent clipping in the highlights no matter what type of lut (csp and cube) we try and no amount of preconditioning is helping... is this just a case of the region render not being fp? Is there a possible fix for this I'm not aware of? -- Jens Lindgren -- Lead Technical Director Magoo 3D Studios http://www.magoo3dstudios.com/
Re: Top List of ICE Nodes That Cover 80% of What You Do With The Toolset
Now that I understand the history of ICE a little better, I can see that I was wrong to balk at naming the top ICE nodes I need. Here's my updated list: car cdr cons eq atom cons quote I suppose I won't really need defun, since Maya will let me just add the same nodes over and over again with a mel script. On Wed, Mar 19, 2014 at 11:56 PM, Raffaele Fragapane raffsxsil...@googlemail.com wrote: The functional programming throwback has officially pushed this conversation into the twilight zone and right out the other end of it into some unexplored surreal territory. Thanks to all involved, it'll stay with me for the rest of my life and make me giggle every time I'll think of it.
Re: Softimage transition webinar is starting in 10 minutes
Maybe they turned off the Softimage webinar right in the middle of us watching it in order to free up some bandwidth for a Maya webinar? On Mon, Mar 17, 2014 at 9:28 AM, Dan Pejril d...@upbeatunique.com wrote: Great job Autodesk! You can't even get a webinar to work properly and we are supposed to believe you can fix Maya by gutting Softimage Useless so far! On 3/17/2014 12:18 PM, Ognjen Vukovic wrote: Thanks autodesk, i just put my foot through a 500 $ dell monitor. On Mon, Mar 17, 2014 at 5:12 PM, Nicolas Esposito 3dv...@gmail.comwrote: Smooth streaming here...they look a bit scared though SPOLIER: Softimage go open source will never happen 2014-03-17 17:08 GMT+01:00 Rob Chapman tekano@gmail.com: it stutters - have to keep clicking on it for playback. hopefully this will be recorded right? On 17 March 2014 16:05, Marc-Andre Carbonneau marc-andre.carbonn...@ubisoft.com wrote: It's actually not working for me. L anyone got it to work? *From:* softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] *On Behalf Of * sku...@gmail.com *Sent:* 17 mars 2014 11:59 *To:* softimage@listproc.autodesk.com *Subject:* Re: Softimage transition webinar is starting in 10 minutes Thank you for the link Marc. I'm finally in the acceptance stage of grief and am resigning myself to using Maya, learning Houdini and continuing to use Softimage as is. I hope they show of some of the upcoming Maya Humanization plans (not just shove ICE into maya). Again, best of luck to all Softimage users out there, but this just fucking sucks... And though this hurts me, best of luck to Autodesk as well too. -- Dan Pejril Upbeat Unique Entertainmentwww.UpbeatUnique.com
Re: Top List of ICE Nodes That Cover 80% of What You Do With The Toolset
Let me ask a very open question to Paul Doyle. Paul when people say the creators of ICE work at Fabric do you agree? Many on the Bifrost team would argue they were just as much a part of it than the hard working guys at Fabric. I think it is great that there are two companies following this path and that will only mean competition which is a good thing but I do believe there are many people who came together and not just 1-2 who drove the whole thing. I don't know what the answer to this is, but as a customer I really don't care that much. I'm far more interested in which development team is innovating and working on not only giving us back what we're losing with ICE, but also addressing its limitations. Given that AD just offed ICE without having a replacement ready, it's going to be a tough sell to convince me AD has a solid vision for the future of the software they sell. AD has all the advantages in terms of size and market share, and I'm 100% confident that there are still some truly exceptional developers working there -- some of whom no doubt worked directly on ICE. I'm also 100% confident the Titanic had a lot of great sailors on board when it sank. Even a tiny lifeboat becomes awfully appealing when the captain of the ship drives it into an iceberg. Let alone a Chinook helicopter (which is how I see Fabric Engine in this analogy. For those who don't think a Chinook helicopter is good enough, remember the Titanic sank in 1912). Since you brought them into this, I'd like to ask an open question to your devs who worked on ICE: Do they feel like their talents are being put to good use? If so, how? I think comparing a list of answers to questions like that would be a lot more productive than counting how many of the people who worked on ICE haven't left AD yet.
Top List of ICE Nodes That Cover 80% of What You Do With The Toolset
On Sat, Mar 15, 2014 at 6:41 AM, Chris Vienneau chris.vienn...@autodesk.com wrote: Do you guys think there is a top list of nodes in ICE and compounds you all use that cover 80% of what you do with the toolset? Nope
Re: Top List of ICE Nodes That Cover 80% of What You Do With The Toolset
Bingo. On Sat, Mar 15, 2014 at 12:31 PM, Bradley Gabe witha...@gmail.com wrote: This is what concerns me about the future for where Autodesk takes their DCC flagships. Bullet-point thinking. It's not any specific list of ICE nodes that make it so powerful and useful, rather it's how well it plays within the data structures of the rest of the application. Everyone who ever looked at ICE from the outside, without ever going into the daily battle that is production, simply saw it as a particle system (and maybe tipped their hat to it's clever ability to multiprocesses). And despite the SI community's repeated insistence ICE was far more important than that, a particle system is precisely how it was marketed by Autodesk, providing continuing evidence that Autodesk didn't know what they actually had, didn't want to listen to the people who were actually using it... or didn't care. In real estate, they say the most important things are location, location, location. In CG production, the most important things are workarounds, workarounds, workarounds. ICE has provided SI users with a highly potent, splendidly integrated, reasonably artist friendly, visual node based toolkit for discovering and developing production workarounds, without having to resort to coding for every little thing. Particle effects are merely a byproduct of the system. It was through interacting with ICE that I developed a much more profound understanding of CG data structures, an intuitive sense of how the linear algebra drives transforms, of how I could influence operators to do the things I could only imagine in times past. Every day in production is a day of experiment and discovery using ICE. Do you have any idea how empowering that feels after years of waiting for technical help from developers that never arrived? Furthermore, after years of tech experimenting and workarounds with ICE, my ability to develop non-ICE tools for animation, deformation, etc, had increased drastically. Tools that used to require a week for me to work out the math, I could develop in less than a day, because ICE had both provided me with enough practice to greatly enhance my thinking, but also because I could use it as a prototype laboratory to quickly hash out more difficult concepts, prior to sitting down to write out the code. If you're wondering why people are concerned about life without XSI, these are some pretty major reasons. You're going to have to convince us the future of node-based work in Maya/Max isn't a bullet point list of nodes for creating particle or fluid sim effects. Rather, that it's a fully developed, operator development kit, from which particles, fluids, simulations, and all kinds of production workarounds, workarounds, workarounds are possible! -Bradley Sent from my iPhone On Mar 15, 2014, at 12:00 PM, Andy Jones andy.jo...@gmail.com wrote: On Sat, Mar 15, 2014 at 6:41 AM, Chris Vienneau chris.vienn...@autodesk.com wrote: Do you guys think there is a top list of nodes in ICE and compounds you all use that cover 80% of what you do with the toolset? Nope
Re: Maya feature request from Softimage users
We should really just release ours. We'd just have to get it cleared with our CTO. But since I built the original version back in the mid 2000s when I was at PLF, it's probably something we can make happen pretty easily. I think we'll also likely want it out there as reference material for a Fabric based scene assembler. We also have an event-based script property thing we made recently, which people might find cool. Not earthshattering, but kinda fun, and would let you do the sorting automatically if you want. Re: contribution maps, let's keep in mind that the special sauce that makes that work in Maya is also a big reason Mental Ray became unusable in Maya. They put so much garbage in the MR version of the Maya shading engine that scenes would sometimes render faster in Soft by an order of magnitude. I spent some time at one point trying to get rid of it, but it was so complicated I eventually realized that even if I found a solution there was no way I could enforce it. I even looked into stripping it via a geometry shader at one point. I think they designed contribution maps without raytracing in mind or something. It's not just contribution maps, but the whole magic maya BS that they tried to cram in there. MayaGlow and whatnot. Also, as mentioned, they're not the same thing as partitions anyway. I could say people should save some time and not bother learning Maya, but the truth is, it's really valuable for learning what not to do in 3D software. Kind of like how it's important to study history so as not to repeat it. On Saturday, March 8, 2014, Andy Goehler lists.andy.goeh...@gmail.com wrote: On Mar 08, 2014, at 23:47, Jonah Friedman jon...@gmail.comjavascript:_e(%7B%7D,'cvml','jon...@gmail.com'); wrote: You manually update them by hitting sort or sort all. Also have a check function that checks to see if anything is unsorted and report what. Sounds like something I'll start implementing on Monday. Thanks for the inspiration. Andy
Re: Save Softimage Petition
So, 1500 people and counting isn't enough to at least let it keep collecting dust like Composite or Matchmover, apparently. Yeah, right. On Wed, Mar 5, 2014 at 5:10 AM, Daniel Brassard dbrassar...@gmail.comwrote: Done. On Wed, Mar 5, 2014 at 7:30 AM, Ognjen Vukovic ognj...@gmail.com wrote: I am really really gutted right now, i am probably one of the younger users on the mailing list, i was introduced to softimage back around 2010 and since then my life got a lot easier and i really enjoyed my work. Everything was just so much fun and i had much less overtime.I was seriously investing in softimage, i started to learn python because of soft and ice was something i was dead set on mastering. Damn, its just awefull And i seriously cannot even begging to understand how it is for most of you long time users, im seriously very very sorry, and i think this is just bullshit. This petition needs to get more exposure and it would be best spread across linkedin and facebook or whatever. On Wed, Mar 5, 2014 at 1:11 PM, michael johansson mich...@lowend.sewrote: Signed 2014-03-05 12:32 GMT+01:00 Ognjen Vukovic ognj...@gmail.com: Signed. On Wed, Mar 5, 2014 at 12:19 PM, Byungchul Kang k...@cgndev.comwrote: done!!! 2014-03-05 20:16 GMT+09:00 Chris Marshall chrismarshal...@gmail.com: Signed. There's over 1000 on there now, which is more than I thought there'd be. Well done! On 5 March 2014 11:03, Nicolas Esposito 3dv...@gmail.com wrote: Done, please share, maybe something can be done ( hopefully ) but I don't trust Autodesk at all 2014-03-05 11:53 GMT+01:00 Eric Mootz e...@mootzoid.com: hell, yes: DONE! -- Chris Marshall Mint Motion Limited 029 20 37 27 57 07730 533 115 www.mintmotion.co.uk -- *Byungchul Kang* | MBC CG TEAM [http://imbc.com] http://cgndev.com -- Michael Johansson Artist/Senior Lecturer/Researcher Kristianstad University Digital Design 29188 Kristianstad Email michael.johans...@hkr.se Infobloom Grönegatan 4a 222 24 Lund Email: mich...@lowend.se www.lowend.se www.abadyl.com
Re: Softimage 2015 Last Release Announcement
If it helps, Angus, as someone who deals with interviewing and crewing/staffing people, I can tell you that for us, it is far more important to find people who understand how to seek out the best tool they can find for every job and actually put it to use, rather than people who just want to tick a box in a list of job requirements. Ticking the box is of course important for freelancers at a more senior level on short term gigs, but at the junior level, what we care about is potential, the drive to push that potential, and personality. (And outstanding artistic and/or technical abilities, of course). For example, all things being equal, a kid who walks in and can actually hold his own in a conversation with me about how to migrate his skillset from Softimage often stands a way better chance than someone who comes in and says he knows Maya. (We are mostly Maya based in LA). On Wed, Mar 5, 2014 at 7:27 AM, Angus Davidson angus.david...@wits.ac.zawrote: When we switched from maya to softimage we had an immediate improvement in what they were able to deliver. I have no regrets about that. I can understand their frustration though, the job market is hard when your starting out and they dont really have anywhere else to vent. Sparing with Luc Eric has given me a thick skin ;) Just shows how AD$K's decision has much bigger knock on effects then they realise. -- *From:* Maurício PC [goneba...@gmail.com] *Sent:* 05 March 2014 05:19 PM *To:* softimage@listproc.autodesk.com *Subject:* Re: Softimage 2015 Last Release Announcement If your students are slamming you Angus, they are stupid. The knowledge of Softimage is easily transferable as it teach you how to think properly. I'm certain they would be less artists if they started with the Maya-hell. Oh well ... I'm almost buying this Modo 701 special offer. Damn. On Wed, Mar 5, 2014 at 7:13 AM, Angus Davidson angus.david...@wits.ac.zawrote: Great getting past students slamming our decision to teach Softimage on facebook. Not sorry for teaching the best software for DCC. However we will have to teach something else from next year ;( This communication is intended for the addressee only. It is confidential. If you have received this communication in error, please notify us immediately and destroy the original message. You may not copy or disseminate this communication without the permission of the University. Only authorised signatories are competent to enter into agreements on behalf of the University and recipients are thus advised that the content of this message may not be legally binding on the University and may contain the personal views and opinions of the author, which are not necessarily the views and opinions of The University of the Witwatersrand, Johannesburg. All agreements between the University and outsiders are subject to South African Law unless the University agrees in writing to the contrary. -- gonebadfx.com - your source for bad fx This communication is intended for the addressee only. It is confidential. If you have received this communication in error, please notify us immediately and destroy the original message. You may not copy or disseminate this communication without the permission of the University. Only authorised signatories are competent to enter into agreements on behalf of the University and recipients are thus advised that the content of this message may not be legally binding on the University and may contain the personal views and opinions of the author, which are not necessarily the views and opinions of The University of the Witwatersrand, Johannesburg. All agreements between the University and outsiders are subject to South African Law unless the University agrees in writing to the contrary.
Re: A way forward - We are kingmakers.
I'll take a stab (although I haven't really spent any time using it). Often in production, we face problems that need solving. They can be generic problems that are common across a studio, like fur or grass, or they can be show-specific, like create time-lapse footage of a building being constructed. These examples are fairly small in scope, but studios may have even broader needs, like We'd like a way to visualize our models quickly, without turntables, with an embedded Shotgun page for doing reviews. There are lots of tools at our disposal for solving these things, but the most powerful toolsets all exist with various DCC packages. So any solution you come up with tends to be tightly coupled with one package. For example, a studio might come up with a good procedural forest solution in Houdini, but then every time they want to use it, they have to make sure they have a Houdini artist to run it. If the rest of the show is in Maya, you now have to deal with porting lots of assets over, and the additional crew. Or, more often, the technical artist or rnd person gets asked to simply port the tool over to the other package. Once you port the tool, you now have two separate sets of code to keep up to date, and eventually you have to hire more technical artists and RnD guys to keep up with demand. And the ones you have are unhappy because they're spending time keeping code in sync and porting features back and forth, rather than making cool stuff artists want. Perhaps the most common situation is that we see all of the issues above in advance, and opt to have an artist figure it out themselves, or do it by hand. Not because us technical guys are lazy beer-sipping jerks, but because it's actually cheaper to do it the hard way than to make a tool that will have to get rewritten by the time you use it again. From what they've released so far, Fabric Engine goes a long way towards remedying these kinds of situations, and does so in a very clever way, that's geared for extremely high performance and flexibility. At its core, Fabric Engine gives us an API for graphics built with multi-threading and optimized machine level compiling in mind. With the Splice integrations in various DCC packages, we gain a direct way to integrate tools built in Fabric Engine into all our DCC packages with a single implementation. The tool you make for Maya Splice works in Softimage Splice, and does so far more elegantly than any one-off tool a TD is likely to create. Magic. So, for the artist, it means your studio can build better tools faster, and make better use of them across packages. Gone are the days of seeing what someone has in tool X and wishing you had it in Y. Also, gone are the days of worrying about building a toolset for a package (say, Softimage) and losing your RD investment overnight because a publicly traded corporation thinks you should be using a clunky pile of aging Mel scripts with serious scalability and workflow problems instead. ***If Fabric Engine can improve the return on investment of RnD, you not only make better use of the RnD resources, but in the long term, you are incentivized to increase the RnD budget.*** Now, taking it one step further, we've made use of sites like rray.de, xsibase, creative crash, etc. Imagine if every new script or tool someone wrote could work in all the Spliced packages! The same arguments about RnD budgets at the company level apply to the community efforts as well. Not only do we get better utilization from the efforts people are making, but there's also a stronger incentive for developers to make more tools, because they can reach a wider audience. And on top of that, FE gives you a license for personal use, so there's nothing stopping individuals from contributing tools right now. The situation we're in now is a chicken/egg scenario. In order for all of the above to take off and revolutionize our industry, we need an audience of studios and individuals ready to consume all of these tools people will make. It's still very early days, so it's not in any way too late for this to happen -- if anything it's probably closer to being too soon. What I mean is, this isn't like Softimage, where the industry is turning a blind eye to a great tool. It's exactly the opposite, as some studios (MPC, Hybride) have already site licensed, when the tools are just getting off the ground. Given what's happening right now, there's a very unique opportunity with a captive audience of Softimage users on a 2-year ticking clock. Just by showing an increase of interest and sales, the value of FE is already growing on paper, which can help a young company get where they need to go even faster. That's my pitch. No affiliations with FE whatsoever, but that's how I see it playing out. No guarantees it will happen, but I do believe the potential is there. It's important to note that a move in the direction of FE by no means has to be a move away from other DCCs. Just as
Re: let me fan the flames....
I sort of agree about the Max userbase, but they will lose Max market share at an ever increasing rate due to all the rumors having dramatically more credibility now. If you're a Max user, would you hedge your bets on them not killing it, or would you learn something else? And if you're a company and everyone seems to be moving away from Max, would you invest in it? They would have to make a really grand gesture to establish faith that it's moving forward, and having watched the grand gesture for Maya, I'm not sure they're capable of it being grand enough. Also, a lot of Max's staying power has been due to FX. With an influx of Houdini talent, and lost trust form 3rd party devs as well, it'll be an uphill battle keeping their position in FX in place. On Wed, Mar 5, 2014 at 11:27 AM, Rares Halmagean ra...@rarebrush.comwrote: The market place will force AD to consolidate it's resources on one package, or significantly modify existing apps, or it fails regardless of user base. The competition is only getting stiffer and it can't hold onto multiple packages in their current state. That's my thought anyway. On 3/5/2014 1:10 PM, Steven Caron wrote: i agree with the first two, just 3dsmax has too much installed user base. i know we are mad and we are making a stink about it... but if they axed max?! autodesk might have to consider extra security... On Wed, Mar 5, 2014 at 11:06 AM, Jordi Bares jordiba...@gmail.com wrote: The writing is on the wall. This is my take. 1 - Mudbox is next as Zbrush has truly wiped the market. 2 - Morion Builder next as they implement some tech in maya. 3 - 3DMax goes next. Anyone want to bet? -- *Rares Halmagean ___ *visual development and 3d character content creation. *rarebrush.com* http://rarebrush.com/
Re: let me fan the flames....
Maybe they're planning to migrate the rest of their dev team to Maya and replace it with one new guy? On Wed, Mar 5, 2014 at 5:02 PM, Alok Gandhi alok.gandhi2...@gmail.comwrote: I don't think Max is going anywhere. The last I heard, AD was looking for a principal max engineer. I interviewed fir the same a couple of months ago.
Re: A way forward - We are kingmakers.
Since the rumor/news broke (and to a certain extent, before that as well), I've been putting some serious thought into plans for the future, and I want to share a few thoughts, as I think this storm will be best weathered together. Every studio is different, of course, so what works for me right now may not work for everyone. To be clear, these are my own speculations at this time, and NOT any kind of formal plan for my employer. The community discussion will have a big impact on our own internal discussions, though, so I think it is important to be part of the dialog. As we all plow forward, the hope is that we will leave a trail that makes it easier for anyone who eventually finds themselves on the same pathway. -- SCENE ASSEMBLY For us, the biggest hole left by Softimage's demise will be lighting and scene assembly. This, and FX, are the main areas where we currently utilize Softimage, particularly in our NY office, but in LA as well. I'm going to run through some of the options I've looked at, leading up to what I think will be a good solution at the bottom. Process of elimination style. - KATANA I've spent some (non-hands-on) time looking at Katana, and while it is a solid, powerful, scaleable solution to scene assembly, I feel it is actually too open-ended at the surface to address our needs. I'm also not satisfied with how it presents shader networks to the end user. I appreciate the flexibility of a nodal system at the core of an application, but what I actually want is a simplified UI that exposes all of that procedural power in a direct and consistent way. I could see where Katana would work well for larger scale projects, but I have major concerns about how it would fare in small 1-10 man operations for commercials. A key requirement for me in a scene aggregator is also the ability to have an ICE-like procedural layer passing data directly to the renderer without caching to disk. Caching is great for things with a certain data to computational complexity ratio, but in so many cases, you're better off either with a procedural callback, or data in memory. Simple grass systems, feathers, hair, fur, rocks, leaves, fuzz, etc. Largely with the help of ICE, we have graduated to an era where surfaces that need it can have more than just high res textures and displacement. The issues above are likely fixable in Katana, but getting a procedural FX framework is far less likely to happen in the timeframe we'd need. For us, Katana being Linux only, also happens to be an issue (though one we could work around with enough motivation). - MAYA With my last two jobs having been mostly in Maya studios, I don't consider Maya an option for scene assembly. The big beefs I have here are essentially the same as what I mentioned with Katana, plus the frequency of instability, and the lack of compartmentalization in the data model. Not being able to group sets and namespaces being nothing more than a naming convention are also big issues. Obviously, people, including ourselves do some great work lighting in Maya, but I work with some of the smartest and most talented Maya people I know, and it is a simple fact that their days are longer and harder than they should be because of Maya, and that situation hasn't changed at all in the last 5 years, aside from the work that's been done by Chaos Group and Solid Angle and the MtoA community. One would think that Maya would actually be a pretty good choice, which I suppose is how we've ended up in this predicament we're in now, and people thinking they've chosen a winning horse with Maya. But the fact is, there has been little done to improve the situation for far too long, and some of the problems seem to be far too deeply rooted in the software to get fixed. It's not entirely negligence on AD's part, as there are a lot of big studios relying on certain things in Maya NOT changing. - HOUDINI I'm not actually finished assessing Houdini's potential for scene assembly and lighting, but I'm already aware of a couple of big issues there. First, Houdini's pricing model is not structured to be conducive to in-process rendering. This means that any run-time procedurals need to be specially built for each renderer. For example, if you wanted to avoid writing a grass system to disk, you would need to use something special purpose to generate the grass at render time (in the best case scenario leveraging an existing hair procedural) or simply write every blade of grass out to an ifd/ass. With the work SideFX is doing on Houdini engine, maybe there's some hope to get a swiss army knife Houdini procedural into the renderers, but it doesn't seem like that's the usage case they have in mind for Houdini engine. Price is the other big issue with Houdini for scene assembly. I have every intention of making use of Houdini as a core FX package, and the price (while still high) is more tenable in that department. As a studio, we already own a smattering of
Re: A way forward - We are kingmakers.
Yes, that's totally my bad. I should have already given you a shout out about FabricArnold. You, and guys like you, are the reason I think doing scene assembly in Fabric is such a likely reality. It's a huge contribution already. I need to get my feet wet in Fabric Engine myself, but I'm hoping to be able to focus some effort on this stuff as well :) hey andy this is the first step in creating something like the 'stage' demo from fabric engine... https://github.com/caron/FabricArnold i am excited about this and would love to collaborate with others in making this a possibility. i agree and understand all you have outlined below.
Re: A way forward - We are kingmakers.
Many studios having the same problems at the same time is a HUGE opportunity if we leverage it properly. I completely agree about the collaboration that will be necessary from users. However, for studios' part, I know a lot of places are interested in Fabric already, even if they haven't actually bought licenses yet. So if part of the incentive was some kind of agreement for the FE guys to help nurture a scene assembly tool to life quickly, it might help tip the scale for whatever cost/benefit analysis places are doing. The devs working on Fabric are truly some of the best in the world (and from what I understand, a big part of the reason AD bought Softimage to begin with). They are a big part of the equation for what will happen in the future, even if they don't end up wanting to build a scene assembler as a supported product in itself (or who knows -- maybe they will?). It would be great to get a little (or big?) list of studios that are interested in this sort of project (or other ones) and possibly have some kind of summit with the FE guys about what it would take to fast-track FE into certain critical areas of production, assuming a certain number of licenses were purchased. No commitments at this point -- just a list of interested parties who might be curious enough to be part of the conversation, pending whatever other conversations need to be had with superiors. I.e., it's understood that nobody is speaking for their companies at this point. Just indicating that they think their company *might* be interested. I'll start: Psyop Massmarket On Tue, Mar 4, 2014 at 1:18 PM, Felix Geremus felixgere...@googlemail.comwrote: You are probably right. But these times are a little bit different and maybe that's exactly the one chance inside all this mess. We're all sitting in the same boat at the same time. I know a lot of studios who entirely rely on Softimage for lighting. All of these will have to spend time and thus money to move on to another pipeline during the next two years anyway. So why not invest at least parts of this time into the same thing? Individuals are great, and the community should absolutely try. But it's so hard to put something like this together in your spare time. A few studios supporting and profiting from this effort would accelerate the whole process immensely. And about showing potential: wasn't Stage, and all the other fabric applications build for exactly this reason? To show the potential of such a project? 2014-03-04 21:55 GMT+01:00 Steven Caron car...@gmail.com: it is a bit harder for visual effects vendors/studios, in an already difficult market, spending money on software development (not their core business) is a hard sell. seeing a product or product in development on the other hand drums up interest which leads to real investment and collaboration. they need to see if their ideas are aligned with others on the project. don't take my comment as discouragement, it is just how i see it... for now it will be on individuals to come together on a project which shows potential. i hope we, the remaining softimage community, can do that together. again, not discouragement to any studio which wants to partner to make something happen... steven On Tue, Mar 4, 2014 at 12:34 PM, Felix Geremus felixgere...@googlemail.com wrote: So now that Softimage will be gone, isn't there room or even need for collaboration here? Before everybody tries to build something themselves, shouldn't people try to bundle forces? And I'm not only talking about individuals here. I'm talking about small to medium size companies who couldn't afford to build something like this alone.
Re: DOSCH HDRI
I would not recommend these, if it's the set I'm thinking of. There was one set we bought years and years ago, which turned out to basically be bad cg environments rendered as spheres with really bad emissive surfaces, and lacking a proper linear workflow. Some of their early photographic HDRIs also didn't seem to be in linear space. I think maybe once they got into the extreme high-res ones they started getting better? Another thing about HDRIs -- early on you could get something out of using a good HDRI in some other environment. These days, not so much. The standard is set by people projecting an HDRI taken from their original scene onto geometry. And in many cases, people are rebuilding the important lights more specifically with corresponding native light sources. I don't know your specific application, so take it with a grain of salt, but reflecting a random HDRI from Dosch onto your cg just isn't really cutting it anymore. On Wed, Feb 12, 2014 at 8:04 PM, Leoung O'Young digim...@digimata.comwrote: Anyone have used the HDRI imagery from Dosch Design? We are thinking of purchasing it. Thanks, Leoung http://www.doschdesign.com/products/hdri/Industrial_Reflections.html
Re: rumor, Soft dead within the next year
It doesn't change anything about the job market, but one thing to keep in mind about rumors from Autodesk: I may have it wrong, as I'm by no means a lawyer but I believe if there were an actual rumor about Autodesk's plans that wasn't issued publicly in a press release, it would be illegal, since people in the know could sell Autodesk stock on any rumors that Softimage would be getting shelved (the assumption being that the surge of new Houdini Modo users would have some negative impact on AD stock prices). It's certainly possible for a legitimate leak of information to occur, but it most likely wouldn't be coming from anyone who _really_ knows what the plan is. If it were, that person would be taking a very big risk. Point being, I would take anything labeled as a rumor with a grain of salt. I'm not naive -- most things like this do originate somewhere. My guess would be that most such rumors are coming from AD employees trying to fend off ongoing questions about the future from industry people like us. So they might have some grain of truth behind them, but anything with a timestamp like within the year is likely to be somebody's own speculation. On Thu, Jan 2, 2014 at 9:03 AM, Stephen Davidson magic...@bellsouth.netwrote: I am extremely lucky to work freelance, so that I am not directed to use any particular software for any particular project. As long as it looks good, my customers are oblivious to what software I am using. Whenever I did work for a production facility, on site, I have always managed to justify their license purchase. It has a lot to do with the length of experience that I have on Softimage. So... I use what works best for me ... Softimage ... has since version 1.0 At least, with all my 3D work. I have tried 3D Max and Maya, just to see if they could improve my workflow. I guess I am too entrenched in Softimage to be able to wrap my head around other 3D app's interface. The others just seem so clumsy. I realize it is because I am used to a certain ingrained workflow that I have developed over the years. The recent addition of RedShift3D render software has improved the render speeds, and quality, immensely. I doubt RedShift would put that much effort into supporting Softimage, as well as Maya, if they thought Softimage was going away any time soon. If Softimage goes away, which I doubt it will, I will probably learn to work Blender, as open source seems to live on forever. It probably has something to do with the cost. :) BTW... didn't Maya used to be called Wavefront ? Happy New Year, all! On Thu, Jan 2, 2014 at 10:46 AM, Mirko Jankovic mirkoj.anima...@gmail.com wrote: taking refuge in Maya?? No thank you! better slow but painless death in never improved SI, like falling asleep slowly.. then looong torture and painful life in Maya! No thank you! SI.. I'm going down with you.. in the next 10-20 years... On Thu, Jan 2, 2014 at 4:42 PM, Jeffrey Dates jda...@kungfukoi.comwrote: I'd think whomever makes the suite of scripts and plugins for Maya for the Softimage refugees soon to be converting over would certainly have a built-in base of users. I also think there is an opportunity for a Fabric Engine Developer to capture some of the refugees with the same thinking... On Thu, Jan 2, 2014 at 6:22 AM, Szabolcs Matefy szabol...@crytek.comwrote: Actually, I am fairly experienced with Maya, yet I feel that it's a wheelchair with square wheels compared to Softimage. However, I see development in Maya a lot more than in Softimage. Houdini is quite out of my scope, being a character artist :). The fact is, if I want to get hired by a game development company, I have to learn Maya and Max, and I have to promote it. So my current project of Vinnie Jones went into Maya, and yes, it's quite painful, because some things are rather clumsy in Maya...:( But I want to get hired, and the companies who I want to work for are mostly Maya based companies. Max is pain in the ass, really, clumsy, mediocre, etc. UK is on my list to get a job there, but last year I was too lazy...This year I want to change a lot, and take my family to a better place :) Cheers PS. I hope that new Softimage will have a lot more for us, and will kick some Max and Maya ass. Chris Chia, will it? -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] On Behalf Of Tim Leydecker Sent: Thursday, January 02, 2014 11:37 AM To: softimage@listproc.autodesk.com Subject: Re: rumor, Soft dead within the next year Hey Szabolcs, even with your credentials? Fauna, a Tutor, etc. Judging on your email address, I would have thought you´d be 3DsMax centric at work, due to the Z-up preferences of the Cryengine and the tools/plugins available for a solid 3DSMaxCryengine workflow. Here´s a few Maya secrets I´d like to share: Embrace Maya accepting that you will need a
Python Shader Definition - Geometry Shader Output Type?
Has anyone attempted to make a custom shader definition for a Mental Ray geometry shader? I've been trying to define the right output type (the dark grey thing), but none of the available constants seem to work. (I actually tried them all one by one, including other values not documented). I found the docs of all the different types: http://download.autodesk.com/global/docs/softimage2013/en_us/sdkguide/index.html?url=si_om/siShaderParameterDataType.html,topicNumber=si_om_siShaderParameterDataType_html Also, I found this: http://download.autodesk.com/global/docs/softimage2013/en_us/sdkguide/index.html?url=si_om/XSIApplication.RegisterShaderCustomParameterType.html,topicNumber=si_om_XSIApplication_RegisterShaderCustomParameterType_html Which would theoretically let me add my own type? Perhaps I just need to make a definition for the existing geometry shader input type? Any thoughts?
Re: Autodesk´s Sales model
I think there's a separate argument about how much support should actually cost for Softimage, given the amount of work being done on the AD side. Provided the support price is in line with the support being provided, I can see where getting rid of upgrades simplifies things a lot. So, I'm not opposed to the idea, but I think it would help the pill go down easier if the support price were lowered some to reflect the efficiencies being gained by AD by getting rid of upgrades. Thinking as a collective of users, we also gain more from people staying on the latest version and keeping the new stuff well-tested. I know there are all kinds of production considerations concerning stability, etc, which still apply, but if every place has access to the latest stuff, it will likely still go into use sooner, regardless of how conservative a studio chooses to be with running new versions. And I agree, the price of support should have dropped to at least half as soon as Stephen left the building. On Wed, Oct 16, 2013 at 7:08 AM, Eric Thivierge ethivie...@hybride.com wrote: Support was worth it when Stephen Blair was there. :) To be fair, the support was worth it to get bugs confirmed and have them provide workarounds if possible or QFEs if available to fix those issues. At larger studios the AD Consulting is worth it when you can get it when you're in the trenches and need bugs fixed asap that are blocking. Eric T. On Wednesday, October 16, 2013 9:59:28 AM, Mirko Jankovic wrote: Is it? would be interesting pool how many of guys used support. Most of the people, maybe I'm wrong but got that impression, are first coming to list and forums for any help. Could be mistaken. I guess support is more important on larger systems, trying to install on different OS and need some expert advice but on small environments and studios.. not much problems there? :) Again could be mistaken.. but someone else recently mentioned never ever needed support but also looking first in forums
Re: Would you like to recover your scene?
Yeah, my point isn't that replaying the commands is currently a viable alternative for scene recovery (though I would say it's better than nothing in the cases where the auto-recovery fails). Just that it could be a really good solution, if some more effort were put into ensuring every interaction got logged as a command of some kind. And since a lot of people rely on command logging as a way to build scripts, they'd be killing two birds with one stone. The plugin is just a proof of concept. A journaling approach just seems like a better way to deal with file recovery than a weird last-second binary dump, especially given that the dump often contains the thing causing the crash in the first place and has no way to handle things like power outages, auto-logouts, etc. There's no reason 3D software can't be as robust with file recovery as Nuke is. Even if there are commands that can't be logged for some reason, you could have a special dirty state that triggers a normal auto-save in those instances to ensure that the journal-based recovery can still work properly. On Fri, Sep 6, 2013 at 8:58 PM, Matt Lind ml...@carbinestudios.com wrote: My only beef with your plugin is it cannot account for commands which do not log. There’s a good probability the scene your plugin generates is not an accurate representation of what last state of the scene actually was before it crashed. Animation edits, for example, do not log at all. Custom tools flagged to not log, or tools called from self installing commands do not log either. Back in good ol’ days of XSI v6.x when we were treading water to get anything to function in XSI without exploding, I desperately tried to salvage crashed scenes using a similar technique, but because many commands were not logged it was not possible to salvage work or even rebuild it enough to send to Softimage to diagnose the cause of the crash to get it fixed. Critical missing steps caused the rebuild script to error out, or if it was lucky enough to get to the end without error, the end result was not at all like what it should’ve been. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Andy Jones Sent: Friday, September 06, 2013 8:44 PM To: softimage@listproc.autodesk.com Subject: Re: Would you like to recover your scene? I've said this before, but the script log comes really really close to implementing journalling which is the thing that made filesystems more robust in the 2000's. the binary dump emergency save thing is really kind of a silly way to attack the problem of replaying a journal of operations. If Autodesk realized this, they'd prioritize the completeness of command logging and build a simple toolset for replaying the unsaved operation journal. I sent my repeatHistory plugin to the beta list a while ago and got crickets. Maybe I'll try again... All it does is parse the script log for the last open or save operation and them exec the remainder. It would work even better with an event that sets the script log path on scene open/save. On Friday, September 6, 2013, Jeremie Passerin wrote: Got issue with the auto-recover lately, but the scene was actualy properly saved before crashing. just needed to load it manually. http://xsisupport.com/2011/10/15/crash-recovery-in-softimage/ On 6 September 2013 13:18, Eric Thivierge ethivie...@hybride.com wrote: You're doing it wrong... On September-06-13 4:15:36 PM, Eric Lampi wrote: SoftImage: Hey Eric, I see that you crashed.. How would you like to recover your scene? Eric: Sure that would be great! Go right ahead, bring it on back! SoftImage You'll get nothing and like it! Meh Eric Freelance 3D and VFX animator http://vimeopro.com/user7979713/3d-work
Re: Would you like to recover your scene?
I'd love an ascii scene file format as much as the next guy, but people still lose plenty of unsaved changes with Maya ascii. Aside from general hackability, the big advantage of .ma is being able to fix broken scenes after they've been saved. On Sat, Sep 7, 2013 at 9:48 AM, Toonafish ron...@toonafish.nl wrote: Word ! That would save sooo many lives. - Ronald On 9/7/2013 18:23, Octavian Ureche wrote: Native ascii scene file format. Period. Though we've been asking for it forever now. -Octav On Sat, Sep 7, 2013 at 6:58 AM, Matt Lind ml...@carbinestudios.com wrote: My only beef with your plugin is it cannot account for commands which do not log. There’s a good probability the scene your plugin generates is not an accurate representation of what last state of the scene actually was before it crashed. Animation edits, for example, do not log at all. Custom tools flagged to not log, or tools called from self installing commands do not log either. Back in good ol’ days of XSI v6.x when we were treading water to get anything to function in XSI without exploding, I desperately tried to salvage crashed scenes using a similar technique, but because many commands were not logged it was not possible to salvage work or even rebuild it enough to send to Softimage to diagnose the cause of the crash to get it fixed. Critical missing steps caused the rebuild script to error out, or if it was lucky enough to get to the end without error, the end result was not at all like what it should’ve been. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Andy Jones Sent: Friday, September 06, 2013 8:44 PM To: softimage@listproc.autodesk.com Subject: Re: Would you like to recover your scene? I've said this before, but the script log comes really really close to implementing journalling which is the thing that made filesystems more robust in the 2000's. the binary dump emergency save thing is really kind of a silly way to attack the problem of replaying a journal of operations. If Autodesk realized this, they'd prioritize the completeness of command logging and build a simple toolset for replaying the unsaved operation journal. I sent my repeatHistory plugin to the beta list a while ago and got crickets. Maybe I'll try again... All it does is parse the script log for the last open or save operation and them exec the remainder. It would work even better with an event that sets the script log path on scene open/save. On Friday, September 6, 2013, Jeremie Passerin wrote: Got issue with the auto-recover lately, but the scene was actualy properly saved before crashing. just needed to load it manually. http://xsisupport.com/2011/10/15/crash-recovery-in-softimage/ On 6 September 2013 13:18, Eric Thivierge ethivie...@hybride.com wrote: You're doing it wrong... On September-06-13 4:15:36 PM, Eric Lampi wrote: SoftImage: Hey Eric, I see that you crashed.. How would you like to recover your scene? Eric: Sure that would be great! Go right ahead, bring it on back! SoftImage You'll get nothing and like it! Meh Eric Freelance 3D and VFX animator http://vimeopro.com/user7979713/3d-work -- Octavian Ureche +40 732 774 313 (GMT+2) Animation Visual Effects www.okto.ro -- Ronald van Vemden --- 3D Graphics Animation Cyberfish Laboratories | www.cyberfish.nl Toonafish | www.toonafish.nl tel. +31(0)20 5289291 fax +31(0)20 5289292 email: ron...@toonafish.nl
Re: Would you like to recover your scene?
I 100% agree and am fully in favor of an ascii scene format. Just pointing out that it alone unfortunately doesn't solve the crash recovery problem. On Sun, Sep 8, 2013 at 3:23 AM, Angus Davidson angus.david...@wits.ac.za wrote: An Ascii file format really is a must. Apart from being able to hack and restore file (which saved many of my students when we were still using Maya, it also allow Czars Git plugin to become far more useful. To be able to run diffs on a scene to find out whats actually changed would be amazing. Kind regards Angus From: Andy Jones [andy.jo...@gmail.com] Sent: 08 September 2013 10:15 AM To: softimage@listproc.autodesk.com Subject: Re: Would you like to recover your scene? I'd love an ascii scene file format as much as the next guy, but people still lose plenty of unsaved changes with Maya ascii. Aside from general hackability, the big advantage of .ma is being able to fix broken scenes after they've been saved. On Sat, Sep 7, 2013 at 9:48 AM, Toonafish ron...@toonafish.nl wrote: Word ! That would save sooo many lives. - Ronald On 9/7/2013 18:23, Octavian Ureche wrote: Native ascii scene file format. Period. Though we've been asking for it forever now. -Octav On Sat, Sep 7, 2013 at 6:58 AM, Matt Lind ml...@carbinestudios.com wrote: My only beef with your plugin is it cannot account for commands which do not log. There’s a good probability the scene your plugin generates is not an accurate representation of what last state of the scene actually was before it crashed. Animation edits, for example, do not log at all. Custom tools flagged to not log, or tools called from self installing commands do not log either. Back in good ol’ days of XSI v6.x when we were treading water to get anything to function in XSI without exploding, I desperately tried to salvage crashed scenes using a similar technique, but because many commands were not logged it was not possible to salvage work or even rebuild it enough to send to Softimage to diagnose the cause of the crash to get it fixed. Critical missing steps caused the rebuild script to error out, or if it was lucky enough to get to the end without error, the end result was not at all like what it should’ve been. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Andy Jones Sent: Friday, September 06, 2013 8:44 PM To: softimage@listproc.autodesk.com Subject: Re: Would you like to recover your scene? I've said this before, but the script log comes really really close to implementing journalling which is the thing that made filesystems more robust in the 2000's. the binary dump emergency save thing is really kind of a silly way to attack the problem of replaying a journal of operations. If Autodesk realized this, they'd prioritize the completeness of command logging and build a simple toolset for replaying the unsaved operation journal. I sent my repeatHistory plugin to the beta list a while ago and got crickets. Maybe I'll try again... All it does is parse the script log for the last open or save operation and them exec the remainder. It would work even better with an event that sets the script log path on scene open/save. On Friday, September 6, 2013, Jeremie Passerin wrote: Got issue with the auto-recover lately, but the scene was actualy properly saved before crashing. just needed to load it manually. http://xsisupport.com/2011/10/15/crash-recovery-in-softimage/ On 6 September 2013 13:18, Eric Thivierge ethivie...@hybride.com wrote: You're doing it wrong... On September-06-13 4:15:36 PM, Eric Lampi wrote: SoftImage: Hey Eric, I see that you crashed.. How would you like to recover your scene? Eric: Sure that would be great! Go right ahead, bring it on back! SoftImage You'll get nothing and like it! Meh Eric Freelance 3D and VFX animator http://vimeopro.com/user7979713/3d-work -- Octavian Ureche +40 732 774 313 (GMT+2) Animation Visual Effects www.okto.ro -- Ronald van Vemden --- 3D Graphics Animation Cyberfish Laboratories | www.cyberfish.nl Toonafish | www.toonafish.nl tel. +31(0)20 5289291 fax +31(0)20 5289292 email: ron...@toonafish.nl = table width=100% border=0 cellspacing=0 cellpadding=0 style=width:100%; tr td align=left style=text-align:justify;font face=arial,sans-serif size=1 color=#99span style=font-size:11px;This communication is intended for the addressee only. It is confidential. If you have received this communication in error, please notify us immediately and destroy the original message. You may not copy or disseminate this communication without the permission of the University. Only authorised signatories are competent to enter into agreements on behalf of the University
Re: Would you like to recover your scene?
I've said this before, but the script log comes really really close to
implementing journalling which is the thing that made filesystems more
robust in the 2000's. the binary dump emergency save thing is really kind
of a silly way to attack the problem of replaying a journal of operations.
If Autodesk realized this, they'd prioritize the completeness of command
logging and build a simple toolset for replaying the unsaved operation
journal.
I sent my repeatHistory plugin to the beta list a while ago and got
crickets. Maybe I'll try again...
All it does is parse the script log for the last open or save operation and
them exec the remainder. It would work even better with an event that sets
the script log path on scene open/save.
On Friday, September 6, 2013, Jeremie Passerin wrote:
Got issue with the auto-recover lately, but the scene was actualy properly
saved before crashing. just needed to load it manually.
http://xsisupport.com/2011/10/15/crash-recovery-in-softimage/
On 6 September 2013 13:18, Eric Thivierge
ethivie...@hybride.comjavascript:_e({}, 'cvml', 'ethivie...@hybride.com');
wrote:
You're doing it wrong...
On September-06-13 4:15:36 PM, Eric Lampi wrote:
SoftImage: Hey Eric, I see that you crashed.. How would you like to
recover your scene?
Eric: Sure that would be great! Go right ahead, bring it on back!
SoftImage You'll get nothing and like it!
Meh
Eric
Freelance 3D and VFX animator
http://vimeopro.com/**user7979713/3d-workhttp://vimeopro.com/user7979713/3d-work
Re: something to cheer you guys up a bit :)
Stop. Fabricate and listen?
On Thursday, August 1, 2013, Miquel Campos wrote:
I am in the Fabric Engine list. The Splice list is another one?
Miquel Campos
www.miquelTD.com
2013/8/1 Helge Mathee helge.mat...@gmx.net javascript:_e({}, 'cvml',
'helge.mat...@gmx.net');
still looking for beta testers, I'll push on this next week, so anybody
who wants to drive the development a little let me know, or just sign
up for the splice list. (b...@fabricengine.com javascript:_e({},
'cvml', 'b...@fabricengine.com');)
On 8/1/2013 8:44 PM, Alan Fregtman wrote:
Awesome news indeed! :)
Can't wait to see what we can... *fabricate.*
*
*
On Thu, Aug 1, 2013 at 1:18 PM, Miquel Campos
miquel.cam...@gmail.comjavascript:_e({}, 'cvml',
'miquel.cam...@gmail.com');
wrote:
+1 Super great news!
Miquel Campos
www.miquelTD.com
2013/8/1 Eric Thivierge ethivie...@hybride.com javascript:_e({},
'cvml', 'ethivie...@hybride.com');
Don't count on it! Since my bug fix requests go unanswered for
Softimage as of late, my new solution across all applications is to start
leaving notes on cars and in mailboxes along with animal sacrifices. :D
Seriously though, this is great news guys and thanks for pushing ahead
with this. I'm looking forward to getting this going and what the future
will hold for us.
Eric Thivierge
===
Character TD / RnD
Hybride Technologies
On August-01-13 12:49:21 PM, Paul Doyle wrote:
Eric might stop stalking the Montreal employees as well, which would
be nice.
Re: Car-setup
One tip is to make sure you've got a plan in mind for how to deal with the wheels. There are a few different ways to solve it. Probably the simplest is to render with full 3D motion blur, and use enough transform steps so that the wheels don't do strange things. Of course, this can have an impact on render times, depending on what you're using and how your settings are dialed. Another option is to us a pre-blurred spinny wheel image. Or you can apply a sort of elliptical blur in comp prior to post motion blur. Neither of these techniques produce a physically accurate image, however. True motion blur of wheel rims is a really unique-looking thing that is difficult to recreate by other means. Another option I've used in the past was to temporally oversample and use a motion interpolated retime, such as kronos/oflow/twixtor. At the time, I used a OpenGL so that the render times were low enough to make oversampling viable. Really, for me this was one of the big reasons I decided that the long term future for rendering will be full 3d motion blur, and I try to build my lighting/compositing workflows with that in mind. On Tue, Jul 9, 2013 at 9:13 AM, Pingo van der Brinkloev xsil...@comxnet.dk wrote: No car lovers out there :) On 06/07/2013, at 22.41, Pingo van der Brinkloev xsil...@comxnet.dk wrote: Hey, I have an upcoming project where a car(3D) is driving inbetween shapes, that turn out to be a logo. It's gonna be semi realistic, so I need to make the cars movements believable. I have a fast edit (quick cuts), so I'm probably going to animate by hand (don't think I need dynamics). But if anybody has some heads up, dos and don'ts about car-related animation it'd be greatly appreciated. It's a Formula1 btw. Cheers! P
Re: 2014-2013
You may also want to consider exporting .mi files and having your farm service render using mr standalone if they have it. Or you could possibly do something similar with stand-ins/archives. There are often similar workflows for other renderers. And just a not on the 5 render nodes from command line, if you use a different renderer than mental ray, or are doing non-mental ray processing, you can run unlimited command line instances using the -processing flag. I haven't done it myself, but I suspect using vray with -processing can be pretty cost effective, since you get some rendernodes with your interactive license (right?) On Friday, July 5, 2013, Manny Papamanos wrote: Converting a scene is wasted time imo and may yield bad results at render due to passes and data that doesn’t port over. Personally, I would override the render manager and just render with xsibatch –render [“scenepath”] –skip in a command prompt. You can run on 5 separate terminals to one SI license. Manny Papamanos Autodesk Softimage and MotionBuilder Support From: softimage-boun...@listproc.autodesk.com javascript:; [mailto: softimage-boun...@listproc.autodesk.com javascript:;] On Behalf Of Rob Chapman Sent: Friday, July 05, 2013 8:31 AM To: softimage@listproc.autodesk.com javascript:; Subject: Re: 2014-2013 or try an earlier .xsi version export of the scene made into a model...? On 5 July 2013 12:41, Sandy Sutherland sandy.mailli...@gmail.comjavascript:; mailto:sandy.mailli...@gmail.com javascript:; wrote: Well you could write out caches - then export obj of geometry - go into the previous Softimage, import the obj - load the cache onto it and redo the texture - UV should go with the obj - camera you could try fbx. S. On 2013/07/05 12:38 PM, Pingo van der Brinkloev wrote: I don't evern have caches. This scene is so simple. I'm using 2 texture maps and everything else is super simple animation and geo. Isn't there a cheat? Somehow to get soft to think it's a 2013 scene? P On 05/07/2013, at 12.33, Sandy Sutherland sandy.mailli...@gmail.comjavascript:; mailto:sandy.mailli...@gmail.com javascript:; wrote:
Re: Softimage 2013/2014 Irradiance Particles - IP Optimize still single threaded?
Yeah, I agree. I'm assuming the xsibatch license tokens are tied in with Mental Ray licensing. Given that -processing already allows you to do everything but render, it would be very strange to prevent you from kicking off the execution of a 3rd party plugin. On Sat, Mar 30, 2013 at 10:30 AM, Steven Caron car...@gmail.com wrote: i doubt it, processing flag is there for that exact reason. we have been using for a long time, 2007 maybe. they obviously only care about one renderer. requiring another softimage license would be cost prohibative. they could do a lot of damage if they change this!
Re: Softimage 2013/2014 Irradiance Particles - IP Optimize still single threaded?
Sort of as an aside, we were talking license counts the other day and discovered the -processing license flag. If you didn't know about this, it seems to allow you to not only process scenes with an arbitrary number of Softimage instances, but also lets you render using 3rd party renderers without pulling the limited xsibatch tokens. From what I can tell, you essentially have unlimited command line Softimages, but a fixed number of mental rays. Good news for people looking at 3rd party renderers, as you don't have to factor in the cost of bundled mental ray as you expand your farm, and you don't have to worry about implementing an .ass file pipeline (unless you want to for other reasons). I'm not sure it's actually changed anything in terms of what we would have bought, as we've got a fair number of xsibatch already, but it's just nice to know, and it's making it much easier to roll out a hybrid workflow.
Re: Difference between a force and a velocity ?
The example of running around on a track is wrong unless you're on a stationary planet. Way to confuse Olivier, guys :( Here's my stab: Definitions aside, velocity describes how something is moving at an instant in time. Force, however, is more closely related to how an object will accelerate over time (in that the acceleration of the object is directly proportional to the forces acting upon it). So if a force is acting on an object, that will cause it to start moving differently as time passes, like what happens when you drop something. When you drop a ball, gravity (a force) causes its downward velocity to increase more and more as time passes. A noteworthy exception to this simple explanation of forces and velocity are forces that are actually dependent on velocity. In practice, one of the most common such forces is the force of friction with a surface, such as a table top (or even the surface of air against the object, which is a component of the drag force affecting an object traveling through a medium). For example, as an object travels faster and faster through the air, the force of friction with the air will increase. This is why when you first drop a ball it speeds up on its way down, but once it's falling fast enough, it will stop speeding up and continue at a constant speed (and constant velocity, if you're a stickler for terminology). Once the ball is falling at a fixed speed, you know that the force of gravity and the force of drag/friction are equal and opposite, such that they cancel out. This is of course ignoring secondary effects, such as the heat generated by the people below arguing over email forums about how physics works. In this case, as the arguing increases, the amount of hot air released increases, and the air surrounding the ball becomes thinner, reducing the drag force on the ball, and causing it to fall even faster, thereby increasing the speed at which the ball hits its intended target, hopefully reminding that target that it's silly to get worked up over Newtonian physics, since it's a simplified approximation of reality anyway. - Andy On Wed, Feb 13, 2013 at 3:54 PM, Raffaele Fragapane raffsxsil...@googlemail.com wrote: I don't have an account, please feel free to do so in my place. I googled it though, didn't do all the post myself ;) On Thu, Feb 14, 2013 at 10:24 AM, Steven Caron car...@gmail.com wrote: please add... http://cgmemes.blogspot.com/ On Wed, Feb 13, 2013 at 3:01 PM, Raffaele Fragapane raffsxsil...@googlemail.com wrote: -- Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!
Re: Camera mapping heavily distorted in viewport
I believe the problem is because opengl texture mapping functions implement linear interpolation of the UVs at the vertices, but a camera projection does not interpolate linearly. In order to do a proper hardware-based camera projection, you would need to interpolate the UVs as part of the fragment/pixel shading code. Otherwise, they'd need to add some sort of camera projection texturing mode to the OpenGL standard (assuming they haven't already? I'm not super current on these things.) By subdividing, you gradually converge on a better and better piecewise linear approximation of the camera projection. Like how integrals work. A trick I've used in the past is to apply the camera projection to a diced clone of my object, so that I can do all my modeling, etc underneath, on the lower res object. - Andy On Wed, Nov 7, 2012 at 8:59 AM, Andi Farhall andi.farh...@primefocusworld.com wrote: I've found simple cameramapped planes need some subdivisions to play nice. ** ** A ** ** *From:* softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] *On Behalf Of *Szabolcs Matefy *Sent:* 07 November 2012 08:38 *To:* softimage@listproc.autodesk.com *Subject:* Camera mapping heavily distorted in viewport ** ** Hey folks, I was in trouble in the last two days. I had an image of a room, and I had to build up the room’s walls using simple planes. The image is then cameramapped (or projected) back onto these planes. I wanted to show the client the stuff in the viewport, and I was horrified, that the texture of the image was distorted to the point when I decided I can’t show this to the client. I had to subdivide the planes about ten or more times to have some decent camera mapping. In render it was OK, but the client wanted to render it with HQV. Any idea? I’m especially interested a solution that doesn’t involve too much geometry… ** ** Cheers ** ** Szabolcs ___ This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Crytek GmbH - http://www.crytek.com - Grüneburgweg 16-18, 60322 Frankfurt - HRB77322 Amtsgericht Frankfurt a. Main- UST IdentNr.: DE20432461 - Geschaeftsfuehrer: Avni Yerli, Cevat Yerli, Faruk Yerli
Re: Object Label Channel... Nevermind
Multiplying by coverage is only half of it. You also need to get a 1-pixel edge around your hard matte, and multiply that by the inverse of the pixel coverage, then add the result to the first part. So: Good Matte = (Aliased Matte) * Pixel Coverage + (1-pixel edge of Aliased Matte) * (1 - Pixel Coverage). There's a good chance that will be too much math in AfterEffects, and your compositor will give up. In Nuke, you can build a gizmo, and it ends up being pretty manageable. If you're working with someone else using AE, I recommend generating mattes for them (potentially using the coverage pass as described), to keep the complexity down in the actual comp. Also, keep in mind, this technique doesn't work well with semi-transparent objects, motion blur, or depth of field. It only solves the problem for hard cg edges. - Andy On Thu, Oct 18, 2012 at 11:15 AM, Byron Nash byronn...@gmail.com wrote: Thanks for the info Eric and Ciaran. I will give that a shot. On Thu, Oct 18, 2012 at 12:05 PM, Eric Lampi ericla...@gmail.com wrote: Hey Ed, Here you go. They were talking about an ObjectID shader, but it seems like this is pretty much the same thing as the current Object Label channel. http://www.si-community.com/community/viewtopic.php?f=28t=340start=10 Eric On Thu, Oct 18, 2012 at 11:13 AM, Ed Manning etmth...@gmail.com wrote: hey eric -- could you post the links you found? (I'm feeling to lazy to google that string myself!) ;-) On Thu, Oct 18, 2012 at 11:03 AM, Eric Lampi ericla...@gmail.comwrote: Murphy's Law applied to email lists, 5 minutes after you send off a help post, you find what you need. I did a search on ObjectID instead of Object Label after seeing someone refer to it... Thanks anyway, Eric -- Freelance 3D and VFX animator http://vimeopro.com/user7979713/3d-work -- Freelance 3D and VFX animator http://vimeopro.com/user7979713/3d-work
Re: Raafal
Maybe it was a decease and desist. Zing. On Thu, Oct 11, 2012 at 11:06 AM, Matt Lind ml...@carbinestudios.comwrote: Author died? I heard the project was given a 'cease and desist' order from the courts for copyright/patent infringement. Matt -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau Sent: Thursday, October 11, 2012 10:20 AM To: softimage@listproc.autodesk.com Subject: Re: Raafal a fun fact for everyone. A french guy did start to make a Softimage|3D (not XSI) open source clone back in the late 1990s! It was called Moonlight|3D! (yep, cloned the | pipe as well) Here is a screenshot: http://www.creativecrash.com/downloads/applications/3d-apps/c/moonlight-3d-atelier The author died around the year 2000. Moonlight 3D still continues today, but in name only; the new team writes in Java and they have dropped the Softimage legacy.
Re: Raafal
The 2020's appeared as a holographic avatar and recommended that the
buttons be enormous, 3-dimensional, and semi-transparent, so you can use
them with a gestural display on augmented reality headwear.
On Wednesday, October 10, 2012, Eric Thivierge wrote:
Maybe that's because you're from the 80s era? :P The 1990s called and
want their fuzzy bevels and oblong rounded corners back.
Eric Thivierge
http://www.ethivierge.com
On Thu, Oct 11, 2012 at 9:26 AM, Greg Punchatz
g...@janimation.comjavascript:_e({}, 'cvml', 'g...@janimation.com');
wrote:
Why not?..they make me feel warm and fuzzy ;)
--
*Greg Punchatz*
*Sr. Creative Director*
Janimation
214.823.7760
www.janimation.com
Re: Running Softimage from the network (central install)
I can't speak from personal experience with Softimage running from a network, but one thing to keep in mind is that Linux (specifically NFS) does a much better job than Windows (specifically CIFS/SMB) of caching files and not always pounding the network over and over again for the same stuff. I like the rsync idea a lot. Anytime files are being read multiple times, and rarely written is a good place to deploy that sort of strategy. On Centos 6, there's a thing called FS-Cache that does persistent caching of network files. At the last place I worked, we talked about it briefly, in the context of application deployment, but it was still too early for Centos 6. And now I'm back on Windows :( - Andy On Mon, Oct 8, 2012 at 8:28 PM, Alan Fregtman alan.fregt...@gmail.comwrote: At work when we start up XSI we rsync from the network copy so it's local but updates can be deployed easily should we make a change. (Linux, too.) On Mon, Oct 8, 2012 at 8:25 PM, Raffaele Fragapane raffsxsil...@googlemail.com wrote: It can be done easily enough, and we do it for test versions before they are rolled out to local deployment, and I did it at home for a hwile, mostly for shits and giggles. These days it's not bad at all, but of course the loading times will go up a chunk depending on network related factors, but not by absurd amounts unless you run a sloth of a network. This is on linux, no idea on windows. On Tue, Oct 9, 2012 at 6:38 AM, Jens Lindgren jens.lindgren@gmail.com wrote: Hehe yeah I know it could be slow, but I just want to test it. We're running Nuke from the network and it loads really fast. /Jens
Re: In case you missed it..
I find it kind of hilarious that the only reason any Softimage users want there to be a Softimage suite is so that they'll feel like they're being treated fairly. None of us actually wants to pay extra money for a bonus Maya or Max license. I'd love to see the Softimage diagram to go alongside the Maya/Max diagram. I think it would be something like this: The Area of Excellence Softimage The Area of Access to Cheap Labor Maya, fbx The Area of Access to Some Good 3rd Party Plugins Max The Area of Unfair Marketing The Area I'm mostly kidding of course, but I think there's also a nugget of truth. If Autodesk pushed Softimage as a standalone product and succeeded, good luck selling people suites of redundant products.
Re: ICE in Maya is an engineer's worst nightmare
I really think the fact that Sony built Katana to manage their large scene complexity rather than somehow pipelining Maya speaks to a fundamental lack of scalability inherent in the organization of the scene graph. Look at a render layer in the hypergraph. There are nodes, but the nodes that exist have little regard for streamlining execution. I think for scalability beyond what ICE and lots of RAM offers, you have to be thinking in terms of cloud computing, cluster computing, and similar distributed models. GPU computing essentially follows a similar need for a mapReduce scheme as well, as you need to be able to manage the large data sets in a massively parallel way in order for them to be useful. Honestly, though, I think building scalability on this magnitude is far more feasible for specialized tools designed to solve a particular problem (like a massive fluid sim) than as a modified framework for a general application. The reason is that unless you're talking about a specific tool (city generator, fluid sim, etc) actual scene content is human-bound, and therefore already mapReduced by the production workflow. Beyond that, the scene graph's purpose is to be a top-down interface to the entire scene graph. By it's nature it either fits everything at once, or has to load pieces on demand and/or use a proxy representation system in order to be useful as a complete view of your scene. Personally, I think for any of the big 3 apps, the scalability answer actually has more to do with offloading than changing the architecture. And the irony there is that offloading is actually a relatively simple problem to solve, compared to modifying node-based workflows. Exocortex will probably streamline it between the three apps long before Autodesk does. I mean, they're already well on their way with their Alembic plugin products. Once scenes are offloading efficiently, you simply design your specialty software to talk to the same offloading protocol, or act as a plug-in in software that already speaks that protocol. The bleeding edge for scene scalability is found in render software, not DCC apps. And it's pretty much always been that way. - Andy On Thu, Sep 6, 2012 at 9:30 AM, Williams, Wayne wayne.willi...@xaviant.com wrote: What I'd like to know is how the devs feel about the core of Maya in comparison to Soft now that they have access to the code (I'm guessing this is the case, please let me know if wrong). Are there any things you devs see that were done extremely well in Maya and Soft could have taken a cue from in that regard or vice versa? I realize that you can't go into specifics but figured I'd put the general question out there. -wayne -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Stefan Kubicek Sent: Thursday, September 06, 2012 12:05 PM To: softimage@listproc.autodesk.com Subject: Re: ICE in Maya is an engineer's worst nightmare Fair enough and agreed on, but why would Maya be a better candidate to be developed in that direction than any other app? On Thu, Sep 6, 2012 at 11:22 AM, Stefan Kubicek s...@tidbit-images.com wrote: Scalability is a good buzzword, but what does it actually mean? In the specific context of FX, scalability means very large number of objects, billions of particles, huge fluid grids, etc. Stuff that may not even fit in RAM at once. Juhani's mention of Katana is a good one; it doesn't just everything in RAM at once and process it the way traditional apps do, it creates a receipe that will run in the renderer as needed. For very large data sets, different tools and approach are required other than just adding more RAM to a single PC and doing things the old way. It's also difficult to reference, track, change all those assets if the system isn't thought for that. Again, truck vs family car. Does it mean you can process more data in the same amount of time compared to another app? And what kind of data? Procedural geometry? Rendered Images? Does it mean you can load more assets into the same amount of available RAM on a machine compared to another app? How would the automation of such processes need to look like to scale well? Scripted? C++? Node-based like ICE? Multithreading across the board? Or is it a question of architecture rather than which programming language was used to implement it (scripted vs C++)? What does Maya offer in this regard, or where does it differ, to scale well/better than Soft or app X in your opinion? In my experience Softimage offers pretty much the same mechanisms to automate processes and handle scene complexity as Maya does, + ICE on top, and I found it can load a good chunk more data simultaneously than Maya can fit into the same amount of memory, especially when it comes to working with textures and realtime shaders. That was up until two versions ago, maybe that has changed? If
