ice cache: read or write and suimulate possible?
Hey all, is it possible using the cache on file node to switch from reading to writing if a file on disk is *not* found? (similar to the awesome cache tools in emPolygonizer). Having toyed with this, I'm thinking not, since ice doesn't seem to give us any real access to the cache gubbins or on disk info. Tentatively thinking about writing an ice node to do this, but would rather not go through this pain if it can be done with factory nodes. Many thanks, Jules
Re: OT: best python resource site in the world if you're on windows...
It's interesting to see how many modules are not yet available for python 3.x. On 09/11/2012 08:53, Jules Stevenson wrote: http://www.lfd.uci.edu/~gohlke/pythonlibs/ http://www.lfd.uci.edu/%7Egohlke/pythonlibs/ Everything compiled for 64 bit. Whoever runs this deserves more than a medal.
My Friday flashback
I was digging around and found this, Night of the Day of the Dead, the first short film ever done in XSI. It was done during beta of 1.0 of XSI. This was in the day when XSI only had nurbs and no particlesand a few more crashes :) We completed this in about two weeks, the deadline was important, the launch of XSI 1.0 in Montreal.good times. What made this project unique at the time was that it was our first attempt to bring motion capture into our pipeline (the floaty feet kill me) AND it was all edited right inside XSI using the Animation Mixer on cameras...Bleeding edge stuff for the day. http://www.youtube.com/watch?v=5Tb12QUXizMfeature=youtu.be Enjoy
Re: My Friday flashback
Fun mocap demo, :) what year was this? On Fri, Nov 9, 2012 at 9:34 AM, Greg Punchatz g...@janimation.com wrote: I was digging around and found this, Night of the Day of the Dead, the first short film ever done in XSI. It was done during beta of 1.0 of XSI. This was in the day when XSI only had nurbs and no particlesand a few more crashes :) We completed this in about two weeks, the deadline was important, the launch of XSI 1.0 in Montreal.good times. What made this project unique at the time was that it was our first attempt to bring motion capture into our pipeline (the floaty feet kill me) AND it was all edited right inside XSI using the Animation Mixer on cameras...Bleeding edge stuff for the day. http://www.youtube.com/watch?v=5Tb12QUXizMfeature=youtu.be Enjoy
Re: ice cache: read or write and suimulate possible?
We don't have a File Exists node -- that'd be cool to have though -- so I personally don't see how you could do this with factory nodes presently. That said, nothing stops you from writing a C++ ICE node that checks for files existing. On Fri, Nov 9, 2012 at 8:09 AM, Jules Stevenson droolz...@googlemail.com wrote: Hey all, is it possible using the cache on file node to switch from reading to writing if a file on disk is *not* found? (similar to the awesome cache tools in emPolygonizer). Having toyed with this, I'm thinking not, since ice doesn't seem to give us any real access to the cache gubbins or on disk info. Tentatively thinking about writing an ice node to do this, but would rather not go through this pain if it can be done with factory nodes. Many thanks, Jules
Re: ice cache: read or write and suimulate possible?
Without a custom node, the only solution is maybe to re-compute the particle age each frame (using your own attribute) and compare with the one from the file. If it doesn't match, execute the simulated branch and write it to disc. Assuming that the icecache got an attribute like age of course. Just an idea, Guillaume On Fri, Nov 9, 2012 at 10:08 AM, Alan Fregtman alan.fregt...@gmail.comwrote: We don't have a File Exists node -- that'd be cool to have though -- so I personally don't see how you could do this with factory nodes presently. That said, nothing stops you from writing a C++ ICE node that checks for files existing. On Fri, Nov 9, 2012 at 8:09 AM, Jules Stevenson droolz...@googlemail.com wrote: Hey all, is it possible using the cache on file node to switch from reading to writing if a file on disk is *not* found? (similar to the awesome cache tools in emPolygonizer). Having toyed with this, I'm thinking not, since ice doesn't seem to give us any real access to the cache gubbins or on disk info. Tentatively thinking about writing an ice node to do this, but would rather not go through this pain if it can be done with factory nodes. Many thanks, Jules
Re: ice cache: read or write and suimulate possible?
perhabs you could use 2 Cache-on-file-Nodes. [1. Cache on File Node (Reading)] --- Execute [Get Particle Position] - [Array from Set] - [Array Size] - [Test 0] - [Set Data (Sim = True)] [IF (sim = true)] [. all your Nodes] [2. Cache on File Node (writing)] PS: Need some ICE-Tree-Plugin for eMails Am 09.11.2012 16:15, schrieb Guillaume Laforge: Without a custom node, the only solution is maybe to re-compute the particle age each frame (using your own attribute) and compare with the one from the file. If it doesn't match, execute the simulated branch and write it to disc. Assuming that the icecache got an attribute like age of course. Just an idea, Guillaume On Fri, Nov 9, 2012 at 10:08 AM, Alan Fregtman alan.fregt...@gmail.com mailto:alan.fregt...@gmail.com wrote: We don't have a File Exists node -- that'd be cool to have though -- so I personally don't see how you could do this with factory nodes presently. That said, nothing stops you from writing a C++ ICE node that checks for files existing. On Fri, Nov 9, 2012 at 8:09 AM, Jules Stevenson droolz...@googlemail.com mailto:droolz...@googlemail.com wrote: Hey all, is it possible using the cache on file node to switch from reading to writing if a file on disk is *not* found? (similar to the awesome cache tools in emPolygonizer). Having toyed with this, I'm thinking not, since ice doesn't seem to give us any real access to the cache gubbins or on disk info. Tentatively thinking about writing an ice node to do this, but would rather not go through this pain if it can be done with factory nodes. Many thanks, Jules
Re: ice cache: read or write and suimulate possible?
Vincent, thinking about this more, I'm not so sure this will work since i'm working on a frozen cloud - there is no emitter, so there will always be a point position. Guillaume, I shall test :). On Fri, Nov 9, 2012 at 3:30 PM, Jules Stevenson droolz...@googlemail.comwrote: Nice, thanks Guys, vincent, that looks good - will try :) On Fri, Nov 9, 2012 at 3:27 PM, Vincent Ullmann vincent.ullm...@googlemail.com wrote: perhabs you could use 2 Cache-on-file-Nodes. [1. Cache on File Node (Reading)] --- Execute [Get Particle Position] - [Array from Set] - [Array Size] - [Test 0] - [Set Data (Sim = True)] [IF (sim = true)] [. all your Nodes] [2. Cache on File Node (writing)] PS: Need some ICE-Tree-Plugin for eMails Am 09.11.2012 16:15, schrieb Guillaume Laforge: Without a custom node, the only solution is maybe to re-compute the particle age each frame (using your own attribute) and compare with the one from the file. If it doesn't match, execute the simulated branch and write it to disc. Assuming that the icecache got an attribute like age of course. Just an idea, Guillaume On Fri, Nov 9, 2012 at 10:08 AM, Alan Fregtman alan.fregt...@gmail.comwrote: We don't have a File Exists node -- that'd be cool to have though -- so I personally don't see how you could do this with factory nodes presently. That said, nothing stops you from writing a C++ ICE node that checks for files existing. On Fri, Nov 9, 2012 at 8:09 AM, Jules Stevenson droolz...@googlemail.com wrote: Hey all, is it possible using the cache on file node to switch from reading to writing if a file on disk is *not* found? (similar to the awesome cache tools in emPolygonizer). Having toyed with this, I'm thinking not, since ice doesn't seem to give us any real access to the cache gubbins or on disk info. Tentatively thinking about writing an ice node to do this, but would rather not go through this pain if it can be done with factory nodes. Many thanks, Jules
Re: Mental Ray Features, Integration Autodesk's failure
Could not agree more! (except for the Racing Cars, as Taxi Drivers also earn money by just driving cars ;) ). Guillaume On Fri, Nov 9, 2012 at 4:52 AM, Vladimir Jankijevic vladi...@elefantstudios.ch wrote: I see things a little bit different: Cars are not tools. The majority of people is not using them solely to earn money by just driving them. One exception are Racing Cars and their pilots. Cars are made to transport, to move things. That's basically only one function. And they are particularly good at it. All the Airbags, Speed Controls and so on are just addons that make that one function safer or easier to use. You can drive without them. Of course there are different addons for cars in different segments. Different types of cars target different userbases. They are made differently and are specialized to drive in specific ways. Now look at our software, our tools we use everyday to do our jobs, to earn money. They are huge complex packages trying to fit everything in one big box. To please everyone, whatever need they have or in which segment those people work. And they are particularly good at it (pleasing, that is). The problem here is that our tools are a relatively new emergence. Today's business strategies forced the developers of our tools to make them this way. Our whole business segment is a big interdisciplinary pot. We didn't had the time to develop sophisticated segment specific platforms which are able to communicate with each other. It was easier to just make one platform that does everything. And they do it particularly bad (the work they should do). The complexity of what has to be done is exaggerating. The time to support all of this is getting shorter and shorter. How is this supposed to work? Imagine how bad our cars would be if they would need to please everybody to do anything with them related to movement. They would need to be able to build streets, fly, climb, drill tunnels and make other cars to support what they are doing. This is just an awful vision. Just ranting about how bad stuff is implemented is not going to help anybody. It's too late. Today's tools as platforms are just too crippled to really make a difference on how people do they work in the future. The developers, or the managers and businessmen, need to sit back and try to find new structures and new workflows in how we should be able to work. The algorithms and implementation of them are very specific to the various segments and trying to support all of it out of the box won't work anymore. We need to leave stuff behind and go on. Change for the better. And not just add more Airbags. Vladimir On Thu, Nov 8, 2012 at 9:05 PM, Ed Manning etmth...@gmail.com wrote: On Thu, Nov 8, 2012 at 2:05 PM, Matt Lind ml...@carbinestudios.comwrote: No argument on the making existing tools work, but in terms of tool design you make the erroneous assumption everybody wants to create realistic looking renders like you. I’ve largely worked on non-photo real projects where those extra controls you dislike are absolutely necessary and often not enough. This industry is about making looks and scenarios. It’s not always about recreating what you see in front of you. Actually, I agree completely. FWIW, I don't assume that everybody wants to create realistic looking renders. Sometimes I don't want to either -- it all depends on the needs of the job, and lately it's all been make it look more real. My point was that it should be possible, but not necessary, to drill down into low-level functionality in order to do commonplace things. And for better or worse, plausibly realistic rendering is a very common requirement. To beat my car analogy to death -- it shouldn't be necessary for someone to know how to tune a fuel injection system in order to get their car to the supermarket. It's a great thing if someone does take the plunge and learn how to be a racecar mechanic or driver, but as you said, most people can't or won't do that. Anyway, even a racing mechanic doesn't want to break out his toolbox when he wants to go to Kwik-E-Mart. The sad fact is we have enormous variation in education and educability in our workforce, and even if we resist building for the lowest common denominator, we need to consider it when assembling our tools. It's easy to take this too far -- then you end up with C4D, which makes some hard things shockingly easy, but won't let you do some basic things at all. And as far as maintaining compatibility with legacy assets goes, I don't advocate trashing the legacy shader libraries and making them unusable. But is there any reason that, say, the default scene material couldn't be a BSDF version of Phong (or Blinn or Ward or Ashikhmin) with fresnel and energy conservation? Is there a reason the default light can't be, say, mib_photometric? Why shouldn't the default material be updated when technology advances? Wouldn't it help
Re: Friday Flashback
Friday Flashback #93
1999 /Without SOFTIMAGE|3D and mental ray, specifically, those
phenomenal bullet time backgrounds just wouldn't have been possible./
http://wp.me/powV4-2fA
On 02/11/2012 1:44 PM, Stephen Blair wrote:
Friday Flashback #92
Softimage Awards and Recognitions circa 1996.
Includes an Emmy award for the daytime soap As the World Turns :)
http://wp.me/powV4-2dr
On 26/10/2012 11:24 AM, Stephen Blair wrote:
Friday Flashback 91
The Yearning - pushing #Softimage as an intuitive, emotionally
expressive instrument
http://wp.me/powV4-246
On 19/10/2012 8:27 AM, Stephen Blair wrote:
Friday Flashback #90
Softimage NT
http://wp.me/powV4-2b7
It looks like SI|3D v3.0 was the first NT version, but SI|3D Extreme
wasn't NT until v3.5...
For the name change, I think that had already happened by late 94
On 16/10/2012 1:28 AM, Raffaele Fragapane wrote:
Bit late on this, but you marked SI|3D 3.0 as (NT), I thought 3.0
was when it changed name from CE to 3D, but the first NT version
was 3.51 (which might or might not have been version lined up with
winNT 3.51 intentionally).
Memories are a bit fuzzy, I started following Soft after Jurassic
Park, so I think that was 3D already and not CE, but I do remember
when it was announced for windows first and the MS acquisition a
year or two before ('94?)
On Fri, Sep 28, 2012 at 11:48 PM, Stephen Blair
stephenrbl...@gmail.com mailto:stephenrbl...@gmail.com wrote:
Friday Flashback #89
Creative Environment box shots
http://wp.me/powV4-28u
RE: My Friday flashback
Greg, didn't you do a couple of TV spots for a radio station with the XSI beta before that? I seem to remember CDs dividing like amoebas. gray -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Alan Fregtman Sent: Friday, November 09, 2012 10:05 AM To: XSI Mailing List Subject: Re: My Friday flashback Fun mocap demo, :) what year was this? On Fri, Nov 9, 2012 at 9:34 AM, Greg Punchatz g...@janimation.com wrote: I was digging around and found this, Night of the Day of the Dead, the first short film ever done in XSI. It was done during beta of 1.0 of XSI. This was in the day when XSI only had nurbs and no particlesand a few more crashes :) We completed this in about two weeks, the deadline was important, the launch of XSI 1.0 in Montreal.good times. What made this project unique at the time was that it was our first attempt to bring motion capture into our pipeline (the floaty feet kill me) AND it was all edited right inside XSI using the Animation Mixer on cameras...Bleeding edge stuff for the day. http://www.youtube.com/watch?v=5Tb12QUXizMfeature=youtu.be Enjoy attachment: winmail.dat
Re: Python Strangeness: int() and XSI frame number
Playcontrol values are floating point, so sometimes you don't get back an exact integer and print int( 99.999 ) will print 99 On 09/11/2012 1:23 PM, Bradley Gabe wrote: Opening a new XSI scene, the frame range is set from 1 to 100 by default. If I run the following Python code: print Application.GetValue(PlayControl.Out) the output is 100.0 if I try to directly convert it to an integer: print int(Application.GetValue(PlayControl.Out)) the output is 99 Anyone know what is going on?
RE: Mental Ray Features, Integration Autodesk's failure
The sad truth is the rendering integration is not as independent as one would think or like. I've been writing mental ray shaders for a long time (10+ years), and even today am shocked how touchy Softimage is when loading a scene which uses custom shaders not installed on the current computer - 99% of the time it's a hang and crash. In order for me to load an old scene from, say XSI v2.0 when I was developing a particular shader, I have to have the shader from that era installed to get the scene open. When you consider the rest of the rendering system is built like that, that's why a lot of stagnation occurs. Either AD has to be bold and say screw old content for the sake of progress, or we have a slow moving boat for the sake of compatibility. There's also the reality that when a system is iterated over the years, it requires more manpower to take it to the next level. V1.0 may take 2 people, but v2.0 might require a 3rd to help out because the system has gotten larger, more complex and with more moving pieces which must all be done in sync. There's also the fact the system must integrate with other departments such as UI, animation, modeling, and whatever else comes in contact. Over the years the trend has been to have fewer developers on staff. This creates a situation where it's not possible to roll out an iteration in a single release, but instead have to spread it out over two releases due to the constraints of resources. The only true way to get quick iteration is to keep the renderer a standalone and use cheap export scripts to dump the scene at the command line, but of course, that comes at the cost of user friendliness and iteration speed. Not too much different from the good-fast-cheap production triangle. Throw your dart. While shaders can be updated to have additional features, sometimes it's not possible to retain legacy look as some of the technology that needs to be bridged are mutually exclusive. A shader is a front end to those technologies, but to actually make it work as the user envisions is quite the beast. Mental ray does a pretty good job of being that front end, but to get the benefit requires an educated user. No amount of pretty UI is going to change that. That is what users must understand. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Ed Manning Sent: Thursday, November 08, 2012 12:06 PM To: softimage@listproc.autodesk.com Subject: Re: Mental Ray Features, Integration Autodesk's failure On Thu, Nov 8, 2012 at 2:05 PM, Matt Lind ml...@carbinestudios.commailto:ml...@carbinestudios.com wrote: No argument on the making existing tools work, but in terms of tool design you make the erroneous assumption everybody wants to create realistic looking renders like you. I've largely worked on non-photo real projects where those extra controls you dislike are absolutely necessary and often not enough. This industry is about making looks and scenarios. It's not always about recreating what you see in front of you. Actually, I agree completely. FWIW, I don't assume that everybody wants to create realistic looking renders. Sometimes I don't want to either -- it all depends on the needs of the job, and lately it's all been make it look more real. My point was that it should be possible, but not necessary, to drill down into low-level functionality in order to do commonplace things. And for better or worse, plausibly realistic rendering is a very common requirement. To beat my car analogy to death -- it shouldn't be necessary for someone to know how to tune a fuel injection system in order to get their car to the supermarket. It's a great thing if someone does take the plunge and learn how to be a racecar mechanic or driver, but as you said, most people can't or won't do that. Anyway, even a racing mechanic doesn't want to break out his toolbox when he wants to go to Kwik-E-Mart. The sad fact is we have enormous variation in education and educability in our workforce, and even if we resist building for the lowest common denominator, we need to consider it when assembling our tools. It's easy to take this too far -- then you end up with C4D, which makes some hard things shockingly easy, but won't let you do some basic things at all. And as far as maintaining compatibility with legacy assets goes, I don't advocate trashing the legacy shader libraries and making them unusable. But is there any reason that, say, the default scene material couldn't be a BSDF version of Phong (or Blinn or Ward or Ashikhmin) with fresnel and energy conservation? Is there a reason the default light can't be, say, mib_photometric? Why shouldn't the default material be updated when technology advances? Wouldn't it help move people along by making the default versions of things be the latest ones rather than the oldest? You could always have a Classic Mode button
Re: Python Strangeness: int() and XSI frame number
int(x) is such thatIf/x/is floating point, the conversion truncates towards zero. I understand that to mean int() drops the decimal part. Today, I couldn't repro what you described, but I saw a bunch of support cases like that back at Softimage. On 09/11/2012 1:46 PM, Bradley Gabe wrote: Yup, they are type double, but I was assuming the int() function would do a more intelligent conversion. Have to do int(round(value)) whenever converting from float to int. On Fri, Nov 9, 2012 at 12:42 PM, Stephen Blair stephenrbl...@gmail.com mailto:stephenrbl...@gmail.com wrote: Playcontrol values are floating point, so sometimes you don't get back an exact integer and print int( 99.999 ) will print 99 On 09/11/2012 1:23 PM, Bradley Gabe wrote: Opening a new XSI scene, the frame range is set from 1 to 100 by default. If I run the following Python code: print Application.GetValue(PlayControl.Out) the output is 100.0 if I try to directly convert it to an integer: print int(Application.GetValue(PlayControl.Out)) the output is 99 Anyone know what is going on?
Re: Mental Ray Features, Integration Autodesk's failure
Well, they did do this with ICE deprecating the old particles system. I still remember reading You know this day was coming. in the XSI docs. Now look at the huge forward leap that ICE has provided to FX in Softimage. I think when you have a huge number of artists willing to dump one system for a completely new system, the value of retaining legacy pretty much goes out the window does it not? I would've taken that as a wake up call. MR and Autodesk need to understand this, not just on rendering, but multiple aspects of cg production. -Lu On Fri, Nov 9, 2012 at 10:52 AM, Matt Lind ml...@carbinestudios.com wrote: The sad truth is the rendering integration is not as independent as one would think or like. I’ve been writing mental ray shaders for a long time (10+ years), and even today am shocked how touchy Softimage is when loading a scene which uses custom shaders not installed on the current computer – 99% of the time it’s a hang and crash. In order for me to load an old scene from, say XSI v2.0 when I was developing a particular shader, I have to have the shader from that era installed to get the scene open. ** ** When you consider the rest of the rendering system is built like that, that’s why a lot of stagnation occurs. Either AD has to be bold and say screw old content for the sake of progress, or we have a slow moving boat for the sake of compatibility. There’s also the reality that when a system is iterated over the years, it requires more manpower to take it to the next level. V1.0 may take 2 people, but v2.0 might require a 3rd to help out because the system has gotten larger, more complex and with more moving pieces which must all be done in sync. There’s also the fact the system must integrate with other departments such as UI, animation, modeling, and whatever else comes in contact. Over the years the trend has been to have fewer developers on staff. This creates a situation where it’s not possible to roll out an iteration in a single release, but instead have to spread it out over two releases due to the constraints of resources. ** ** The only true way to get quick iteration is to keep the renderer a standalone and use cheap export scripts to dump the scene at the command line, but of course, that comes at the cost of user friendliness and iteration speed. ** ** Not too much different from the good-fast-cheap production triangle. Throw your dart. ** ** While shaders can be updated to have additional features, sometimes it’s not possible to retain legacy look as some of the technology that needs to be bridged are mutually exclusive. A shader is a front end to those technologies, but to actually make it work as the user envisions is quite the beast. Mental ray does a pretty good job of being that front end, but to get the benefit requires an educated user. No amount of pretty UI is going to change that. That is what users must understand. ** ** ** ** Matt ** ** ** ** ** ** ** ** ** ** ** ** *From:* softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] *On Behalf Of *Ed Manning *Sent:* Thursday, November 08, 2012 12:06 PM *To:* softimage@listproc.autodesk.com *Subject:* Re: Mental Ray Features, Integration Autodesk's failure ** ** On Thu, Nov 8, 2012 at 2:05 PM, Matt Lind ml...@carbinestudios.com wrote: No argument on the making existing tools work, but in terms of tool design you make the erroneous assumption everybody wants to create realistic looking renders like you. I’ve largely worked on non-photo real projects where those extra controls you dislike are absolutely necessary and often not enough. This industry is about making looks and scenarios. It’s not always about recreating what you see in front of you. ** ** Actually, I agree completely. FWIW, I don't assume that everybody wants to create realistic looking renders. Sometimes I don't want to either -- it all depends on the needs of the job, and lately it's all been make it look more real. My point was that it should be possible, but not necessary, to drill down into low-level functionality in order to do commonplace things. And for better or worse, plausibly realistic rendering is a very common requirement. To beat my car analogy to death -- it shouldn't be necessary for someone to know how to tune a fuel injection system in order to get their car to the supermarket. It's a great thing if someone does take the plunge and learn how to be a racecar mechanic or driver, but as you said, most people can't or won't do that. Anyway, even a racing mechanic doesn't want to break out his toolbox when he wants to go to Kwik-E-Mart. The sad fact is we have enormous variation in education and educability in our workforce, and even if we resist building for the lowest common denominator, we need to consider it when assembling our tools. It's easy to
Re: the goon kickstarter.
Rock on guys! Way to go! -Tim C. On 11/9/2012 12:52 PM, David Gallagher wrote: Cool. How much is Softimage used at Blur? On 11/9/2012 1:29 PM, Jeremie Passerin wrote: Yeah Thanks everyone ! Jeff just made the announcement a few minutes ago here. On 9 November 2012 10:22, Gustavo Eggert Boehs gustav...@gmail.com mailto:gustav...@gmail.com wrote: Seems like it is a go! Awesome, got to love the power of the intertubes... 2012/11/2 Darren Macpherson darren...@gmail.com mailto:darren...@gmail.com Done. Wish one of the Rewards was 'Immediately hired if you are a 3d artist' D -- *darren macpherson | 3d artist | +2772 355 0924 | **www.darrenmacpherson.com http://www.darrenmacpherson.com| dar...@darrenmacpherson.com mailto:dar...@darrenmacpherson.com | **skype: darren.macpherson* On 2012/11/02 10:30 PM, Jeremie Passerin wrote: Yeah, it seems to be better the last couple of days. I heard you get more pledges on Kickstarter at the beginning and the very end of it... We seem a little short though. Keeping our fingers crossed. Btw, we only hire people who pledged :D On 1 November 2012 11:09, Dan Yargici danyarg...@gmail.com mailto:danyarg...@gmail.com wrote: I pledged some at the start. Would love to see this pick up that last bit of momentum... it seems to have stalled pretty badly :/ DAN On Thu, Nov 1, 2012 at 6:31 PM, Jeremie Passerin gerem@gmail.com mailto:gerem@gmail.com wrote: Hi guys, 9 days left on The Goon Kickstarter. We are still hoping to be funded. A bunch of update are available with a visit of the studio, and one new concept art available each day. Check it out and spread the word ! http://www.kickstarter.com/projects/624061548/the-goon-movie-lets-kickstart-this-sucker/posts cheers, Jeremie -- Gustavo E Boehs http://www.gustavoeb.com.br/blog -- Signature
Re: the goon kickstarter.
Yeah Steven remembers well ;-) Rigging and Animation is all Softimage, the rest is mainly Max. On 9 November 2012 11:03, Steven Caron car...@gmail.com wrote: before i left... modeling, 3dsmax, one guy might still use softimage, shaun. texturing and shading are done in 3dsmax for use in vray layout, mostly 3dsmax some softimage. rigging and animation, softimage environment modeling, 3dsmax lighting and rendering, 3dsmax and vray FX mostly max, one guy uses softimage on occasion, kosnik s On Fri, Nov 9, 2012 at 10:52 AM, David Gallagher davegsoftimagel...@gmail.com wrote: Cool. How much is Softimage used at Blur? On 11/9/2012 1:29 PM, Jeremie Passerin wrote: Yeah Thanks everyone ! Jeff just made the announcement a few minutes ago here. On 9 November 2012 10:22, Gustavo Eggert Boehs gustav...@gmail.comwrote: Seems like it is a go! Awesome, got to love the power of the intertubes... 2012/11/2 Darren Macpherson darren...@gmail.com Done. Wish one of the Rewards was 'Immediately hired if you are a 3d artist' D -- *darren macpherson | 3d artist | +2772 355 0924 | ** www.darrenmacpherson.com** **| dar...@darrenmacpherson.com | **skype: darren.macpherson* On 2012/11/02 10:30 PM, Jeremie Passerin wrote: Yeah, it seems to be better the last couple of days. I heard you get more pledges on Kickstarter at the beginning and the very end of it... We seem a little short though. Keeping our fingers crossed. Btw, we only hire people who pledged :D On 1 November 2012 11:09, Dan Yargici danyarg...@gmail.com wrote: I pledged some at the start. Would love to see this pick up that last bit of momentum... it seems to have stalled pretty badly :/ DAN On Thu, Nov 1, 2012 at 6:31 PM, Jeremie Passerin gerem@gmail.comwrote: Hi guys, 9 days left on The Goon Kickstarter. We are still hoping to be funded. A bunch of update are available with a visit of the studio, and one new concept art available each day. Check it out and spread the word ! http://www.kickstarter.com/projects/624061548/the-goon-movie-lets-kickstart-this-sucker/posts cheers, Jeremie -- Gustavo E Boehs http://www.gustavoeb.com.br/blog
RE: Mental Ray Features, Integration Autodesk's failure
That's great for productions with short timelines as they don't have to worry about the legacy support. The project I'm on now has been going for nearly 8 years and is expected to go for another 5-10 years. In such an environment it's not unusual for an asset to be created and then not touched again for years at a time. When it is touched again, it's usually to fix a bug reported by QA or a customer playing our game. We absolutely cannot afford to have entire systems such as the particle system pulled out from under our feet like that because if such an asset has to be exhumed for a bug fix, we cannot open the scene file anymore and essentially lose the asset. Fortunately we weren't using the particle system at the time so we weren't affected, but the point remains. If we had been using the old particle system and that switch were made today...that would effectively lock us into whatever version of the software we were using at the time for rest of the project. I'm not too keen about spending the next 10 years in Softimage 7.5. Not only for the lack of modern features, but the support issues that go with trying to maintain and keep an old product alive that nobody will support. Just the other day our 7.5 licenses expired. That's right, 'expired'. It shut our production down for a day unexpectedly. I'm sure Autodesk would like to continue receiving subscription payments from us. So there has to be a better path mapped out than what Softimage did with migrating to ICE cold turkey. And that involves better planning of features from the get-go instead of frankensteining them on later. If a cold turkey switch must be made, then the legacy support needs to remain now matter how painful it is to maintain as there are customers with a lot at stake. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Meng-Yang Lu Sent: Friday, November 09, 2012 11:02 AM To: softimage@listproc.autodesk.com Subject: Re: Mental Ray Features, Integration Autodesk's failure Well, they did do this with ICE deprecating the old particles system. I still remember reading You know this day was coming. in the XSI docs. Now look at the huge forward leap that ICE has provided to FX in Softimage. I think when you have a huge number of artists willing to dump one system for a completely new system, the value of retaining legacy pretty much goes out the window does it not? I would've taken that as a wake up call. MR and Autodesk need to understand this, not just on rendering, but multiple aspects of cg production. -Lu On Fri, Nov 9, 2012 at 10:52 AM, Matt Lind ml...@carbinestudios.commailto:ml...@carbinestudios.com wrote: The sad truth is the rendering integration is not as independent as one would think or like. I've been writing mental ray shaders for a long time (10+ years), and even today am shocked how touchy Softimage is when loading a scene which uses custom shaders not installed on the current computer - 99% of the time it's a hang and crash. In order for me to load an old scene from, say XSI v2.0 when I was developing a particular shader, I have to have the shader from that era installed to get the scene open. When you consider the rest of the rendering system is built like that, that's why a lot of stagnation occurs. Either AD has to be bold and say screw old content for the sake of progress, or we have a slow moving boat for the sake of compatibility. There's also the reality that when a system is iterated over the years, it requires more manpower to take it to the next level. V1.0 may take 2 people, but v2.0 might require a 3rd to help out because the system has gotten larger, more complex and with more moving pieces which must all be done in sync. There's also the fact the system must integrate with other departments such as UI, animation, modeling, and whatever else comes in contact. Over the years the trend has been to have fewer developers on staff. This creates a situation where it's not possible to roll out an iteration in a single release, but instead have to spread it out over two releases due to the constraints of resources. The only true way to get quick iteration is to keep the renderer a standalone and use cheap export scripts to dump the scene at the command line, but of course, that comes at the cost of user friendliness and iteration speed. Not too much different from the good-fast-cheap production triangle. Throw your dart. While shaders can be updated to have additional features, sometimes it's not possible to retain legacy look as some of the technology that needs to be bridged are mutually exclusive. A shader is a front end to those technologies, but to actually make it work as the user envisions is quite the beast. Mental ray does a pretty good job of being that front end, but to get the benefit requires an educated user. No amount of pretty UI is
Re: My Friday flashback
We did that stuff in the Alpha versions I believe... back when I considered using untested software in real productions an extreme sport :) *Greg Punchatz* *Sr. Creative Director* Janimation 214.823.7760 www.janimation.com http://www.janimation.com On 11/9/2012 12:07 PM, Grahame Fuller wrote: Greg, didn't you do a couple of TV spots for a radio station with the XSI beta before that? I seem to remember CDs dividing like amoebas. gray
RE: the goon kickstarter.
I don't know if you guys can still call it MAX with so many scripts and plugins holding things together. ;) The important thing is the results. Right. And Blur does deliver amazing results. From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Jeremie Passerin Sent: 9 novembre 2012 14:08 To: softimage@listproc.autodesk.com Subject: Re: the goon kickstarter. Yeah Steven remembers well ;-) Rigging and Animation is all Softimage, the rest is mainly Max. On 9 November 2012 11:03, Steven Caron car...@gmail.commailto:car...@gmail.com wrote: before i left... modeling, 3dsmax, one guy might still use softimage, shaun. texturing and shading are done in 3dsmax for use in vray layout, mostly 3dsmax some softimage. rigging and animation, softimage environment modeling, 3dsmax lighting and rendering, 3dsmax and vray FX mostly max, one guy uses softimage on occasion, kosnik s On Fri, Nov 9, 2012 at 10:52 AM, David Gallagher davegsoftimagel...@gmail.commailto:davegsoftimagel...@gmail.com wrote: Cool. How much is Softimage used at Blur? On 11/9/2012 1:29 PM, Jeremie Passerin wrote: Yeah Thanks everyone ! Jeff just made the announcement a few minutes ago here. On 9 November 2012 10:22, Gustavo Eggert Boehs gustav...@gmail.commailto:gustav...@gmail.com wrote: Seems like it is a go! Awesome, got to love the power of the intertubes... 2012/11/2 Darren Macpherson darren...@gmail.commailto:darren...@gmail.com Done. Wish one of the Rewards was 'Immediately hired if you are a 3d artist' D -- darren macpherson | 3d artist | +2772 355 0924tel:%2B2772%20355%200924 | www.darrenmacpherson.comhttp://www.darrenmacpherson.com | dar...@darrenmacpherson.commailto:dar...@darrenmacpherson.com | skype: darren.macpherson On 2012/11/02 10:30 PM, Jeremie Passerin wrote: Yeah, it seems to be better the last couple of days. I heard you get more pledges on Kickstarter at the beginning and the very end of it... We seem a little short though. Keeping our fingers crossed. Btw, we only hire people who pledged :D On 1 November 2012 11:09, Dan Yargici danyarg...@gmail.commailto:danyarg...@gmail.com wrote: I pledged some at the start. Would love to see this pick up that last bit of momentum... it seems to have stalled pretty badly :/ DAN On Thu, Nov 1, 2012 at 6:31 PM, Jeremie Passerin gerem@gmail.commailto:gerem@gmail.com wrote: Hi guys, 9 days left on The Goon Kickstarter. We are still hoping to be funded. A bunch of update are available with a visit of the studio, and one new concept art available each day. Check it out and spread the word ! http://www.kickstarter.com/projects/624061548/the-goon-movie-lets-kickstart-this-sucker/posts cheers, Jeremie -- Gustavo E Boehs http://www.gustavoeb.com.br/blog
Re: Mental Ray Features, Integration Autodesk's failure
Screw legacy, software will never be clean or robust if you keep adding new stuff while while keeping all the old krusty stuff around. If you need legacy tools use legacy software. Forward *Greg Punchatz* *Sr. Creative Director* Janimation 214.823.7760 www.janimation.com http://www.janimation.com On 11/9/2012 1:11 PM, Matt Lind wrote: That's great for productions with short timelines as they don't have to worry about the legacy support. The project I'm on now has been going for nearly 8 years and is expected to go for another 5-10 years. In such an environment it's not unusual for an asset to be created and then not touched again for years at a time. When it is touched again, it's usually to fix a bug reported by QA or a customer playing our game. We absolutely cannot afford to have entire systems such as the particle system pulled out from under our feet like that because if such an asset has to be exhumed for a bug fix, we cannot open the scene file anymore and essentially lose the asset. Fortunately we weren't using the particle system at the time so we weren't affected, but the point remains. If we had been using the old particle system and that switch were made today...that would effectively lock us into whatever version of the software we were using at the time for rest of the project. I'm not too keen about spending the next 10 years in Softimage 7.5. Not only for the lack of modern features, but the support issues that go with trying to maintain and keep an old product alive that nobody will support. Just the other day our 7.5 licenses expired. That's right, 'expired'. It shut our production down for a day unexpectedly. I'm sure Autodesk would like to continue receiving subscription payments from us. So there has to be a better path mapped out than what Softimage did with migrating to ICE cold turkey. And that involves better planning of features from the get-go instead of frankensteining them on later. If a cold turkey switch must be made, then the legacy support needs to remain now matter how painful it is to maintain as there are customers with a lot at stake. Matt *From:*softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] *On Behalf Of *Meng-Yang Lu *Sent:* Friday, November 09, 2012 11:02 AM *To:* softimage@listproc.autodesk.com *Subject:* Re: Mental Ray Features, Integration Autodesk's failure Well, they did do this with ICE deprecating the old particles system. I still remember reading You know this day was coming. in the XSI docs. Now look at the huge forward leap that ICE has provided to FX in Softimage. I think when you have a huge number of artists willing to dump one system for a completely new system, the value of retaining legacy pretty much goes out the window does it not? I would've taken that as a wake up call. MR and Autodesk need to understand this, not just on rendering, but multiple aspects of cg production. -Lu On Fri, Nov 9, 2012 at 10:52 AM, Matt Lind ml...@carbinestudios.com mailto:ml...@carbinestudios.com wrote: The sad truth is the rendering integration is not as independent as one would think or like. I've been writing mental ray shaders for a long time (10+ years), and even today am shocked how touchy Softimage is when loading a scene which uses custom shaders not installed on the current computer -- 99% of the time it's a hang and crash. In order for me to load an old scene from, say XSI v2.0 when I was developing a particular shader, I have to have the shader from that era installed to get the scene open. When you consider the rest of the rendering system is built like that, that's why a lot of stagnation occurs. Either AD has to be bold and say screw old content for the sake of progress, or we have a slow moving boat for the sake of compatibility. There's also the reality that when a system is iterated over the years, it requires more manpower to take it to the next level. V1.0 may take 2 people, but v2.0 might require a 3^rd to help out because the system has gotten larger, more complex and with more moving pieces which must all be done in sync. There's also the fact the system must integrate with other departments such as UI, animation, modeling, and whatever else comes in contact. Over the years the trend has been to have fewer developers on staff. This creates a situation where it's not possible to roll out an iteration in a single release, but instead have to spread it out over two releases due to the constraints of resources. The only true way to get quick iteration is to keep the renderer a standalone and use cheap export scripts to dump the scene at the command line, but of course, that comes at the cost of user friendliness and iteration speed. Not too much different from the good-fast-cheap production triangle. Throw your dart. While
Re: Mental Ray Features, Integration Autodesk's failure
+1. On 11/9/2012 1:31 PM, Greg Punchatz wrote: Screw legacy, software will never be clean or robust if you keep adding new stuff while while keeping all the old krusty stuff around. If you need legacy tools use legacy software. Forward *Greg Punchatz* *Sr. Creative Director* Janimation 214.823.7760 www.janimation.com http://www.janimation.com On 11/9/2012 1:11 PM, Matt Lind wrote: That's great for productions with short timelines as they don't have to worry about the legacy support. The project I'm on now has been going for nearly 8 years and is expected to go for another 5-10 years. In such an environment it's not unusual for an asset to be created and then not touched again for years at a time. When it is touched again, it's usually to fix a bug reported by QA or a customer playing our game. We absolutely cannot afford to have entire systems such as the particle system pulled out from under our feet like that because if such an asset has to be exhumed for a bug fix, we cannot open the scene file anymore and essentially lose the asset. Fortunately we weren't using the particle system at the time so we weren't affected, but the point remains. If we had been using the old particle system and that switch were made today...that would effectively lock us into whatever version of the software we were using at the time for rest of the project. I'm not too keen about spending the next 10 years in Softimage 7.5. Not only for the lack of modern features, but the support issues that go with trying to maintain and keep an old product alive that nobody will support. Just the other day our 7.5 licenses expired. That's right, 'expired'. It shut our production down for a day unexpectedly. I'm sure Autodesk would like to continue receiving subscription payments from us. So there has to be a better path mapped out than what Softimage did with migrating to ICE cold turkey. And that involves better planning of features from the get-go instead of frankensteining them on later. If a cold turkey switch must be made, then the legacy support needs to remain now matter how painful it is to maintain as there are customers with a lot at stake. Matt *From:*softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] *On Behalf Of *Meng-Yang Lu *Sent:* Friday, November 09, 2012 11:02 AM *To:* softimage@listproc.autodesk.com *Subject:* Re: Mental Ray Features, Integration Autodesk's failure Well, they did do this with ICE deprecating the old particles system. I still remember reading You know this day was coming. in the XSI docs. Now look at the huge forward leap that ICE has provided to FX in Softimage. I think when you have a huge number of artists willing to dump one system for a completely new system, the value of retaining legacy pretty much goes out the window does it not? I would've taken that as a wake up call. MR and Autodesk need to understand this, not just on rendering, but multiple aspects of cg production. -Lu On Fri, Nov 9, 2012 at 10:52 AM, Matt Lind ml...@carbinestudios.com mailto:ml...@carbinestudios.com wrote: The sad truth is the rendering integration is not as independent as one would think or like. I've been writing mental ray shaders for a long time (10+ years), and even today am shocked how touchy Softimage is when loading a scene which uses custom shaders not installed on the current computer -- 99% of the time it's a hang and crash. In order for me to load an old scene from, say XSI v2.0 when I was developing a particular shader, I have to have the shader from that era installed to get the scene open. When you consider the rest of the rendering system is built like that, that's why a lot of stagnation occurs. Either AD has to be bold and say screw old content for the sake of progress, or we have a slow moving boat for the sake of compatibility. There's also the reality that when a system is iterated over the years, it requires more manpower to take it to the next level. V1.0 may take 2 people, but v2.0 might require a 3^rd to help out because the system has gotten larger, more complex and with more moving pieces which must all be done in sync. There's also the fact the system must integrate with other departments such as UI, animation, modeling, and whatever else comes in contact. Over the years the trend has been to have fewer developers on staff. This creates a situation where it's not possible to roll out an iteration in a single release, but instead have to spread it out over two releases due to the constraints of resources. The only true way to get quick iteration is to keep the renderer a standalone and use cheap export scripts to dump the scene at the command line, but of course, that comes at the cost of user friendliness and iteration speed. Not too much different from the good-fast-cheap
polygon island attributes
Hey all, A while ago I asked how to assign random attributes to polygon islands and I've recently revisited that task and used a couple of methods using the get array minimum technique. Currently I'm just assigning purely random values using a random value node which has my custom poly island indices plugged into it. What I'd like to do is find a way to drive each islands value via a worley noise or turbulise node so I can get a more patterned, less random change to the values from island to island. The issue is finding a way to sample the noise at one point for each island and I'm not sure how to go about that. If you have any ideas or could point me to something I'd love to hear from you. Cheers.
Simulating ice trees via xsibatch?
I'm trying to automate some heavy sims by sending them via RR as a xsibatch script, which simply starts 'playforwardsfromstart()', however i'm getting a lot of crashes, which I'm trying to narrow down. Before I go to far down this root, is it actually possible to simulate ice via xsi batch? My google fu is letting me down here. Cheers, Jules
Re: update on Creation integration to Softimage
This pretty much sums me up also, and I've found myself asking the very same questions! I've also been keenly following the development of FE but I'm not sure I have the chops to put it to proper use... Really looking forward to your response! DAN On 10 Nov 2012 01:12, Andy Moorer andymoo...@gmail.com wrote: Helge, I find the creation platform both really exciting, and from what I've seen as it grows its learning curve intimidating. I'm an artist-turned-TD and a script monkey largely educated by watching your jscript videos and lectures at Barnyard, and later taking Raffaele's workshop... plus self training, bothering folks like you, Graham and Brad, and a (nasty) year spent in Mel. In other words, I'm (I think) a pretty typical non-developer technical artist. Is the Creation Platform something for folks like me, who spends about 40% of my time scripting and the rest in creating assets and reasonably complex stuff in ICE? Or is it targeted squarely at TDs who spend the bulk of their time scripting, ie more for those at the developer end of the scale? Not that I'm not willing to always be stretching my capabilities to grow as a TD and artist. I'm just trying to figure out who you see as the typical Fabric Creation Platform user. Kudos to the regular outreach and amazingly fast and production-targeted development of Fabric, it's been really awesome to watch it come to life. On Nov 9, 2012, at 2:53 AM, Helge Mathee helge.mat...@gmx.net wrote: yes - the CreationPlatformCAPI will be shipped working on all three operating systems. On 08.11.2012 23:01, Xavier Lapointe wrote: Had the same question on my mind actually. On Fri, Nov 9, 2012 at 8:58 AM, Eric Thivierge ethivie...@gmail.comwrote: So the integration with Softimage is working on Linux? Eric Thivierge http://www.ethivierge.com On Fri, Nov 9, 2012 at 3:40 AM, Helge Mathee helge.mat...@gmx.netwrote: Linux is fully supported for everything. As is OSX. On 08.11.2012 15:01, Raffaele Fragapane wrote: Hey Helge, This might be of enough general interest to post here rather than in private. How are you guys faring on the linux front these days? On Nov 8, 2012 8:08 PM, Helge Mathee helge.mat...@gmx.net wrote: Thanks guys! Now, I've stated that on the Creation Platform mailing list already: I am aware that people are impressed by the videos we publish and interested in Creation Platform generally. We are doing workshops and user group both in Montreal and London this month, but aside from that I would like to encourage people to start evaluating Creation Platform for production scenarios. I realize that there's a learning curve attached to that, so I am willing to provide as much help as necessary and lead the way for anybody interested in seriously evaluating CP. At this stage I am looking for production references for certain features, so please mail me privately if you are interested in collaborating. Best! -H On 08.11.2012 09:17, Andreas Böinghoff wrote: wow! this is getting more and more exciting! On 11/7/2012 9:06 PM, Paul Doyle wrote: Hi guys – this is a preview of the work that Helge is doing on the Creation Platform API: https://vimeo.com/groups/fabric/videos/53026583 The new API provides full access to all CP features in C++. This includes high performance data access (void * access to internal data) as well as SceneGraph level features such as Undo, Manipulation, Import / Export etc. We’ll be presenting this in more detail at the Softimage London usergroup on Tuesday 13th November ( http://www.softimagecreatives.com/siclondon/?page_id=1218). We’ll be showing this running in Maya (as well as demoing on Softimage again) at our London usergroup on Wednesday 14th November ( http://fabricengine.com/2012/10/creation-workshops-montreal-london/). Let us know what you think. Looking forward to seeing some of you next week :) Paul -- ANDREAS BÖINGHOFF 3D Artist schönheitsfarm production GmbH Co. KG schönheitsfarm hamburg lippmannstrasse 79 22769 hamburg t +4940 432 91 200 %2B4940%20432%2091%20200 f +4940 432 91 222 %2B4940%20432%2091%20222 schönheitsfarm düsseldorf steinstraße 11 40212 düsseldorf t +49211 913 701 0 %2B49211%20913%20701%200 f +49211 913 701 99 %2B49211%20913%20701%2099 schönheitsfarm frankfurt hanauer landstrasse 151-153 60314 frankfurt t +4969 484 484 90 %2B4969%20484%20484%2090 w www.s-farm.de Geschäftsführung Manfred Brunwey DE 214892548 | Amtsgericht Hamburg HRA 95793 -- Xavier
Re: OT: Anyone living in China?
Do u need a guy who is living in China? Or do you need a guy who can speak Chinese? Chris On 9 Nov, 2012, at 6:40 PM, Paul Griswold pgrisw...@fusiondigitalproductions.commailto:pgrisw...@fusiondigitalproductions.com wrote: Are there any Soft users on this list living in China currently (who can speak Chinese) that could help me out? Please contact me off-list. Thanks, Paul attachment: winmail.dat
RE: Simulating ice trees via xsibatch?
Jules - are you caching these sims or ...? Asking because I use RR to do all our Fur caching - which is all Ice based and it generally works very well! S. Sandy Sutherlandmailto:sandy.sutherl...@triggerfish.co.za | Technical Supervisor [http://triggerfish.co.za/en/wp-content/uploads/udf_foundry/images/logo.png] http://triggerfish.co.za/en [http://static.ak.fbcdn.net/rsrc.php/v2/ym/x/lFV-lsMcC_0.png] http://www.facebook.com/triggerfishanimation [https://si0.twimg.com/a/1349296073/images/resources/twitter-bird-white-on-blue.png] http://www.twitter.com/triggerfishza From: softimage-boun...@listproc.autodesk.com [softimage-boun...@listproc.autodesk.com] on behalf of Jules Stevenson [droolz...@googlemail.com] Sent: 10 November 2012 02:31 To: softimage@listproc.autodesk.com Subject: Simulating ice trees via xsibatch? I'm trying to automate some heavy sims by sending them via RR as a xsibatch script, which simply starts 'playforwardsfromstart()', however i'm getting a lot of crashes, which I'm trying to narrow down. Before I go to far down this root, is it actually possible to simulate ice via xsi batch? My google fu is letting me down here. Cheers, Jules
Re: Python Strangeness: int() and XSI frame number
It is will give you the right results if you use int(round(f, 0)) On Fri, Nov 9, 2012 at 1:55 PM, Stephen Blair stephenrbl...@gmail.comwrote: int(x) is such thatIf *x* is floating point, the conversion truncates towards zero. I understand that to mean int() drops the decimal part. Today, I couldn't repro what you described, but I saw a bunch of support cases like that back at Softimage. On 09/11/2012 1:46 PM, Bradley Gabe wrote: Yup, they are type double, but I was assuming the int() function would do a more intelligent conversion. Have to do int(round(value)) whenever converting from float to int. On Fri, Nov 9, 2012 at 12:42 PM, Stephen Blair stephenrbl...@gmail.comwrote: Playcontrol values are floating point, so sometimes you don't get back an exact integer and print int( 99.999 ) will print 99 On 09/11/2012 1:23 PM, Bradley Gabe wrote: Opening a new XSI scene, the frame range is set from 1 to 100 by default. If I run the following Python code: print Application.GetValue(PlayControl.Out) the output is 100.0 if I try to directly convert it to an integer: print int(Application.GetValue(PlayControl.Out)) the output is 99 Anyone know what is going on? --
