Re: something to cheer you guys up a bit :)
*My DCC's telling me No* *But Splice, Splice is telling me Ye* *I dont wanna hurt no Project* *But there is something that I, must confess* * * *I dont see nothing wrong, with a little KL* *I dont see nothing wrong, No* *I dont see nothing wrong, with a little KL* *I dont see nothing wrong* * * *You told me what you want, and I know just what you need, yeah* *So TD bring your problem to me (bring your problem here)* *I'm not fooling around with you, you know my code it true, let me Splice you* *Portable is where I want to be, you can always Scale with me, hey* * * *You know you need someone, someone like me, yeah* *To codify, your every need...and I dont seee*
Re: something to cheer you guys up a bit :)
Looks like we'll be able to do dynamic parenting? On Fri, Aug 2, 2013 at 10:53 AM, Paul Doyle technove...@gmail.com wrote: https://twitter.com/FabricPaul/status/363311468923478016/photo/1 Next week is going to be fun... On 2 August 2013 10:08, Daryl Dunlap twinsnakes...@gmail.com wrote: *My DCC's telling me No* *But Splice, Splice is telling me Ye* *I dont wanna hurt no Project* *But there is something that I, must confess* * * *I dont see nothing wrong, with a little KL* *I dont see nothing wrong, No* *I dont see nothing wrong, with a little KL* *I dont see nothing wrong* * * *You told me what you want, and I know just what you need, yeah* *So TD bring your problem to me (bring your problem here)* *I'm not fooling around with you, you know my code it true, let me Splice you* *Portable is where I want to be, you can always Scale with me, hey* * * *You know you need someone, someone like me, yeah* *To codify, your every need...and I dont seee*
Re: something to cheer you guys up a bit :)
Sounds great. Maya was giving me a headache. On Thu, Aug 1, 2013 at 12:49 PM, Paul Doyle technove...@gmail.com wrote: Hi everyone - now we're back from Siggraph and recovered, we've started working on Spliced Softimage. Should have a first prototype next week. https://twitter.com/FabricPaul/status/362975245562437632/photo/1 The Hybride guys have been doing some awesome stuff with FE already, so I can't wait to get this into their hands soon :) Eric might stop stalking the Montreal employees as well, which would be nice. A description of Spliced Softimage: Creation:Splice will be integrated into Softimage as a new class of custom operators. Each operator can be setup using the SpliceEditor IDE, defining ports, adding removing them etc, very much like the Scripted Operator Editor. The IDE will also contain a KL Source Code editor as well as functionality for dynamically compiling the code etc. Operators defined with the SpliceEditor will become completely portable between all support host applications, such as Maya, Softimage and Nuke, for example. We are not integrating KL into ICE, for a range of reasons. Splice is targeting areas where ICE doesn't work so well, i.e. Fast procedural geometry, kinematics, simulated rigs, custom OpenGL drawing etc Splice solves the portability issues of moving tools between applications, and as such we try to take a consistent approach within applications. This also means I don't get to make up such compelling slogans as Spliced ICE baby, which is frankly disappointing. If you want to understand more about Splice, please visit the webpage: http://fabricengine.com/creation/splice/ Cheers, Paul
Re: Announcing Redshift - Biased GPU Renderer
Congrats! Wish I could get one of those puppies. On Wed, Mar 27, 2013 at 2:20 PM, Ed Manning etmth...@gmail.com wrote: I installed my Titan yesterday, and it bloody screams. Images soon as I get through this project deadline. On Wed, Mar 27, 2013 at 6:47 AM, Mirko Jankovic mirkoj.anima...@gmail.com wrote: SLI and crossfire dio not affect viewport performance in any of 3d application. On Wed, Mar 27, 2013 at 11:12 AM, olivier jeannel olivier.jean...@noos.fr wrote: There was a subject on Redshift Forum about having two grapphic cards. It seems to be possible to keep a quadro for dispaly (as it is significantly better at displaying), and have a Titan dedicated to rendering only (in Redshift you select which card is rendering) as they have a huge amount of cores and faster memory. I think I've red somewhere that Titan has 2600 cores against 256 for the Quadro 4000. After chating with Nicolas the Titan could be around 4 time faster than the Quadro4000 ...Which is huge :) Le 27/03/2013 09:26, Tim Leydecker a écrit : Personally, I´m hesistant to using two or more cards with SLI because of micro stuttering: http://en.wikipedia.org/wiki/** Micro_stuttering http://en.wikipedia.org/wiki/Micro_stuttering If there would be a solution to that, I´d go with two GTX670 w/4GB VRAM, as they are the same GK104´s with a 915MHz chipspeed instead of a 1006Mhz chipspeed as in the reference design GTX680. That could save another 15-35% percent of investment compared to two single chip GTX 680 cards or one GTX Titan. Overclocked versions may use slightly different chip/shader speeds. In any case, as much VRAM as available, as that always helps in many progamms like Mudbox, Redshift and isn´t much of an added cost (comparing 2GB vs 4GB). At a company I worked Mari 1.5.x behaved bitchy unless it was given a Quadro or forced to ignore the actual card´s game heritage. But that may have been solved with 2.0... Cheers, tim On 27.03.2013 08:59, Mirko Jankovic wrote: On the other hand Titan is more expensive than 2 gtx680 if I'm not mistaken... and i bet that with two 680 in SLI, when multi GPU is supported you will have better performance than with 1 titan right? On Wed, Mar 27, 2013 at 8:55 AM, Tim Leydecker bauero...@gmx.de wrote: The GTX Titan is not a gimmick but uses the successor to the chip series used in the GTX 680, e.g. the GT(X) 6xx series uses the GK104, while the GTX Titan uses the GK110. You can find the GK110 in the Tesla K20, too. You could describe the GTX690 as a gimmick, as it uses two GK104 on one card to maximize performance at the cost of higher powerconsumption, noise and heat. The performance gain between a GTX680 and a GTX Titan is roughly 35% and can be felt nicely when using it with higher screenresolutions like 1920x1200 or 2560x1440 and higher antialiasing in games. That´s where the 6GB VRAM of the GTX Titan come in handy, too. Cheers, tim On 27.03.2013 05:24, Raffaele Fragapane wrote: Benchmarking is more driver tuning than it's videocard performance, and if you want to look at number crunching you should look at the most recent gens. The 680 has brought nVIDIA back up top for number crunching (forgetting the silver editions or gimmicks like the titan), and close enough to bang for buck best, but AMD's response to that still has to come. Ironically, though, the 6xx gen is reported as a crippled, bad performer in DCC apps, although I can't say I noticed it myself. It sure as hell works admirably well in mudbox, mari, cuda work, and I've had no issues in maya or soft. I don't really benchmrak or obsess over numbers much though. When this will obsolesce, I will considering AMD again, probably in a couple years. For GPU rendering though, well, that's something you CAN bench reliably with the engine, and AMD might still win the FLOP per dollar run there, so it's not to be discounted. Would be good to know what the redshift guys have to say about it themselves though if they can spare the thought and can actually disclose. On Thu, Mar 21, 2013 at 9:04 PM, Mirko Jankovic mirkoj.anima...@gmail.comwrote: well no idea about pro cards.. really never got financial justification to get one, quadro 4000 in old company didn;t really felt anything much better than gaming cards so... but in gaming segment.. opengl scores in sinebench for example: gtx 580: ~55 7970: ~90 to start with not to mention annoying issue with high segment rotating cube in viewport in SI. 7970 smooth at ~170 fps with gtx580 bfore that.. to point out that the rest of comp is identical only switched card... for the first 30-50sec frame rate was stuck at something like 17 fps... and after that it kinda jump to ~70-80fps... in any case with gaming cards ati vs nvidia there is no doubt. and if you are not using CUDA much then no need to even thing which way to go. Now
Re: Announcing Redshift - Biased GPU Renderer
Ed, did Octane ever release their SI plugin? On Wed, Mar 27, 2013 at 3:23 PM, Ed Manning etmth...@gmail.com wrote: In what spare time I have I'm setting up a shootout between Octane standalone and redshift in SI.
Re: Softimage 2014
I hope they fixed the C# Custom Shader Def loading issue. The SDK example did not load in 2013. On Tue, Mar 26, 2013 at 10:42 AM, Simon Reeves si...@simonreeves.comwrote: It's as if the chap is directly talking to this list ;) Simon Reeves Freelance 3D VFX Artist London, UK *email: si...@simonreeves.com* *website: http://www.simonreeves.com* * * On 26 March 2013 14:30, Jens Lindgren jens.lindgren@gmail.com wrote: This is interesting... i think. http://area.autodesk.com/2014unfold/products/softimage.html#future /Jens On Tue, Mar 26, 2013 at 3:21 PM, Doeke Wartena clankil...@gmail.comwrote: well softimage is listed in top products so that's nice. Now in the list if you click products would be nice. 2013/3/26 Ben Davis benjamincliffordda...@gmail.com Everything after AutoCAD is alphabetically ordered, not as biased for a change. -- Benjamin Clifford Davis 3D artist - Senior Modeler Senior 3D Generalist www.moondog-animation.com office: +33 9 50 04 76 15 mobile: +33 6 88 48 54 50 6 bis avenue des Iles 74000 Annecy FRANCE On Tue, Mar 26, 2013 at 3:15 PM, Ponthieux, Joseph G. (LARC-E1A)[LITES] j.ponthi...@nasa.gov wrote: Interesting. So did anyone notice this? ** ** http://www.autodesk.com/products ** ** ** ** -- Joey Ponthieux LaRC Information Technology Enhanced Services (LITES) Mymic Technical Services NASA Langley Research Center __ Opinions stated here-in are strictly those of the author and do not ** ** represent the opinions of NASA or any other party. ** ** *From:* softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] *On Behalf Of *Stephen Blair *Sent:* Tuesday, March 26, 2013 5:58 AM *To:* softimage@listproc.autodesk.com *Subject:* Re: Softimage 2014 ** ** That's never going to happen, so best get over it. Python v2.7.3 for Linux! On 26/03/2013 4:59 AM, Mirko Jankovic wrote: not cool.. not cool at all... ** ** On Tue, Mar 26, 2013 at 9:57 AM, Doeke Wartena clankil...@gmail.com wrote: And I treat as an insult that Softimage is not in the direct product list after few years under the Autodesk flag… ** ** +1 for that ** ** 2013/3/26 Piotrek Marczak piotrek.marc...@gmail.com Thanks, that's cool :) 2013/3/26 Ahmidou.xsi ahmidou@gmail.com ** ** It's a c++ plugin in which you draw openGL like the custom tools, but it's hosted by an object. You also have a callback to define what to do when concerting to real geometry. Le 26 mars 2013 à 19:36, Piotrek Marczak piotrek.marc...@gmail.com a écrit : I dont see it in SDK, how do actually customize the way primitive is drawn in viewport (like implicit rings etc).. 2013/3/26 Mirko Jankovic mirkoj.anima...@gmail.com It would be good to see that list as well, maybe that would help out easy bashing all around. people are pretty much disappointed and if new features are only thing that they actually see.. it is understandable that everyone is asking what has bin done in the last full year and that this should be maybe .5 release instead :) ** ** On Tue, Mar 26, 2013 at 9:24 AM, Eugen Sares softim...@keyvis.at wrote: For now, it's only in the beta forum, as it looks. 216 is the exact count, so the new guys did a mighty good job, no matter what new features anybody is still going to miss, and the wheel will keep on turning for another while... Am 26.03.2013 09:04, schrieb Mirko Jankovic: Is there complete release notes with all bug fixes as well? ** ** On Tue, Mar 26, 2013 at 8:37 AM, Eugen Sares softim...@keyvis.at wrote: Worth mentioning is also that more than 200 bugs have been fixed. Am 26.03.2013 07:55, schrieb Juhani Karlsson: This makes interesting contrast with the latest Modo release. : ) - J On 26 March 2013 08:10, Ahmidou Lyazidi ahmidou@gmail.com wrote: Also, the HQV demo is kind of a fail, the ambient occlusion is full of artifacts, and you can see how slow it is to refresh at the end when he move the PPG... --- Ahmidou Lyazidi Director | TD | CG artist http://vimeo.com/ahmidou/videos 2013/3/26 Raffaele Fragapane raffsxsil...@googlemail.com: It's funny, one of the most relevant ones that got quite a few TDs excited is probably going to fly miles under the radar :) On Tue, Mar 26, 2013 at 2:45 PM, Ahmidou Lyazidi ahmidou@gmail.com wrote: The custom primitives are missing from the new feature list... --- Ahmidou Lyazidi Director | TD | CG artist http://vimeo.com/ahmidou/videos 2013/3/26 Luc-Eric Rousseau luceri...@gmail.com: http://www.autodesk.com/products/autodesk-softimage/overview -- Our users will know fear
Re: Announcing Redshift - Biased GPU Renderer
Congrats on getting this up and going. I signed up for access. Do you have any ballpark for where you think your price point will come in at? On Wed, Mar 13, 2013 at 3:18 PM, Nicolas Burtnyk nico...@redshift3d.comwrote: Thanks Alok! That'a an excellent question. We don't currently have any official support for farm rendering. That being said, with a suitable render manager or some hand rolled scripts, I don't see why you couldn't have multiple machines working on different frames of an animation. And of course, we do plan on having more complete render farm support in the future. Your concern regarding the hardware configuration of render nodes is very valid. Redshift does require a GPU and we do not fall back on CPU in the absence of a suitable GPU. The performance gap is so large that it didn't really make sense for us at this stage to invest the time in making this kind of thing work (though we could entertain this possibility). Unfortunately, this does mean that some farms will not be good candidates for Redshift, particularly those in which adding a GPU to some or all of the nodes is not possible (e.g blades with no space in them). Keep in mind though that with the performance improvement factor provided by Redshift, you can get the performance of a farm with a dozen nodes from a single GPU-equipped node. We don't want to make any hard performance claims yet, but our internal tests are often showing 10x to 20x the performance of MR and VRay, sometimes more (on suitably complex scenes - super simple 10 seconds to render in MR stuff doesn't get 10x faster). So maybe you keep your existing farm for CPU renders and add a few GPU equipped nodes for Redshift. On Wed, Mar 13, 2013 at 11:45 AM, Alok alok.gan...@modusfx.com wrote: Congrats on your achievement, looking forward to see more of it. Just a quick question. For most of the render farm setups, usually the machines do not have high-end GPU's on them for the obvious reason that farm nodes never get user interaction and hence no need for realtime graphic intensive processing operations. Do you see that as a problem ? If yes then how would you address it. Does Red Shift turn to CPU for rendering in absence of the required GPU. ALOK GANDHI / chef directeur technique - lead technical director alok.gan...@modusfx.com T: *450 430-0010 x225 F: 450 430-0009 www.modusfx.com - MODUS FX 120 Rue Turgeon, Sainte-Therese (Quebec) CANADA J7E 3J1 Follow us on Facebook http://www.facebook.com/ModusFX Twitter https://twitter.com/Modusfx * On 13/03/2013 2:33 PM, Nicolas Burtnyk wrote: Yes - I'll try to make a video of that if I can get set up correctly for it. Note that this is 2 mins on a GTX 470 which is nothing special in terms of GPUs. You can expect significantly better times with a GTX 580 for example. I don't have official times for that card, but I'd guess under 1.5 minutes. These kinds of times really underscore the power of biased rendering. When you need to reduce noise, you have a lot more options than let's just throw a ton more samples at the whole thing. On Wed, Mar 13, 2013 at 11:28 AM, olivier jeannel olivier.jean...@noos.fr wrote: The classroom is *really* 2min render ? Congrats to you, sending a request :) Le 13/03/2013 19:18, Steven Caron a écrit : congrats to you and your team! i was wondering when we would see/hear about your work. it would be great to see a video demonstration of redshift in softimage. On Wed, Mar 13, 2013 at 11:12 AM, Nicolas Burtnyk nico...@redshift3d.com wrote: Hello folks, In March of last year, 2 colleagues and I left our jobs as software developers in the games industry to form our own company - Redshift. Our goal was to apply our experience with graphics hardware to the problem of offline rendering. Artists friends had been asking us for years why Mental Ray and other renderers were not taking advantage of the GPU. As the ideas bounced around in our heads, we figured we'd take a crack at it. As it turns out, it's really freakin' hard, but not impossible! Today, we're very excited to announce the official launch of Redshift v0.1 alpha, to our knowledge, the world's first fully GPU-accelerated biased renderer. Redshift supports multiple GI solutions: Brute-Force GI, Irradiance Caching (aka Final Gather), Irradiance Point Cloud (aka Light Cache) and Photon Mapping (GI and Caustics). All are fully GPU-accelerated and perform many times faster than similar CPU-based offerings. A problem that plagues many GPU renderers on the market is that they are limited by the available VRAM on the graphics card (and most systems have significantly less VRAM than main memory). Redshift addresses this by using an out-of-core architecture for geometry and textures allowing you to render scenes
Re: Announcing Redshift - Biased GPU Renderer
Steve, thanks for the link to the FAQ. I'm also pleasantly surprised to see some Documentation there as well. :-] On Wed, Mar 13, 2013 at 3:43 PM, Nicolas Burtnyk nico...@redshift3d.comwrote: Redshift does indeed use CUDA and is therefore currently limited to NVidia hardware. However OpenCL support is definitely in our plan, though not in the immediate term (in other words it's not something we're working on at the moment). On Wed, Mar 13, 2013 at 12:32 PM, Mirko Jankovic mirkoj.anima...@gmail.com wrote: grats on progress. I guess that renderer is tightly bind to CUDA and OpenCL versions like for AMD cards are not in plan? On Wed, Mar 13, 2013 at 8:23 PM, Daryl Dunlap twinsnakes...@gmail.comwrote: Congrats on getting this up and going. I signed up for access. Do you have any ballpark for where you think your price point will come in at? On Wed, Mar 13, 2013 at 3:18 PM, Nicolas Burtnyk nico...@redshift3d.com wrote: Thanks Alok! That'a an excellent question. We don't currently have any official support for farm rendering. That being said, with a suitable render manager or some hand rolled scripts, I don't see why you couldn't have multiple machines working on different frames of an animation. And of course, we do plan on having more complete render farm support in the future. Your concern regarding the hardware configuration of render nodes is very valid. Redshift does require a GPU and we do not fall back on CPU in the absence of a suitable GPU. The performance gap is so large that it didn't really make sense for us at this stage to invest the time in making this kind of thing work (though we could entertain this possibility). Unfortunately, this does mean that some farms will not be good candidates for Redshift, particularly those in which adding a GPU to some or all of the nodes is not possible (e.g blades with no space in them). Keep in mind though that with the performance improvement factor provided by Redshift, you can get the performance of a farm with a dozen nodes from a single GPU-equipped node. We don't want to make any hard performance claims yet, but our internal tests are often showing 10x to 20x the performance of MR and VRay, sometimes more (on suitably complex scenes - super simple 10 seconds to render in MR stuff doesn't get 10x faster). So maybe you keep your existing farm for CPU renders and add a few GPU equipped nodes for Redshift. On Wed, Mar 13, 2013 at 11:45 AM, Alok alok.gan...@modusfx.com wrote: Congrats on your achievement, looking forward to see more of it. Just a quick question. For most of the render farm setups, usually the machines do not have high-end GPU's on them for the obvious reason that farm nodes never get user interaction and hence no need for realtime graphic intensive processing operations. Do you see that as a problem ? If yes then how would you address it. Does Red Shift turn to CPU for rendering in absence of the required GPU. ALOK GANDHI / chef directeur technique - lead technical director alok.gan...@modusfx.com T: *450 430-0010 x225 F: 450 430-0009 www.modusfx.com - MODUS FX 120 Rue Turgeon, Sainte-Therese (Quebec) CANADA J7E 3J1 Follow us on Facebook http://www.facebook.com/ModusFX Twitter https://twitter.com/Modusfx * On 13/03/2013 2:33 PM, Nicolas Burtnyk wrote: Yes - I'll try to make a video of that if I can get set up correctly for it. Note that this is 2 mins on a GTX 470 which is nothing special in terms of GPUs. You can expect significantly better times with a GTX 580 for example. I don't have official times for that card, but I'd guess under 1.5 minutes. These kinds of times really underscore the power of biased rendering. When you need to reduce noise, you have a lot more options than let's just throw a ton more samples at the whole thing. On Wed, Mar 13, 2013 at 11:28 AM, olivier jeannel olivier.jean...@noos.fr wrote: The classroom is *really* 2min render ? Congrats to you, sending a request :) Le 13/03/2013 19:18, Steven Caron a écrit : congrats to you and your team! i was wondering when we would see/hear about your work. it would be great to see a video demonstration of redshift in softimage. On Wed, Mar 13, 2013 at 11:12 AM, Nicolas Burtnyk nico...@redshift3d.com wrote: Hello folks, In March of last year, 2 colleagues and I left our jobs as software developers in the games industry to form our own company - Redshift. Our goal was to apply our experience with graphics hardware to the problem of offline rendering. Artists friends had been asking us for years why Mental Ray and other renderers were not taking advantage of the GPU. As the ideas bounced around in our heads, we figured we'd take a crack at it. As it turns out, it's really freakin' hard, but not impossible! Today
Re: Announcing Redshift - Biased GPU Renderer
Nicolas, the docs say you support model instancing. But, do you also support instancing via PointClouds (Particle instancing)? On Wed, Mar 13, 2013 at 4:21 PM, Nicolas Burtnyk nico...@redshift3d.comwrote: We support 32 bit because it's not any more difficult to do so and doesn't impact the performance or anything on 64 bit. Basically, why not? :) On Wed, Mar 13, 2013 at 1:00 PM, Matt Morris matt...@gmail.com wrote: Looking forward to seeing some more samples, just wondering why you continue to support 32-bit, given that autodesk have dropped support in the more recent versions? Does it add much overhead? Scuse my uninformed ponderings ;) On 13 March 2013 19:43, Nicolas Burtnyk nico...@redshift3d.com wrote: Redshift does indeed use CUDA and is therefore currently limited to NVidia hardware. However OpenCL support is definitely in our plan, though not in the immediate term (in other words it's not something we're working on at the moment). On Wed, Mar 13, 2013 at 12:32 PM, Mirko Jankovic mirkoj.anima...@gmail.com wrote: grats on progress. I guess that renderer is tightly bind to CUDA and OpenCL versions like for AMD cards are not in plan? On Wed, Mar 13, 2013 at 8:23 PM, Daryl Dunlap twinsnakes...@gmail.comwrote: Congrats on getting this up and going. I signed up for access. Do you have any ballpark for where you think your price point will come in at? On Wed, Mar 13, 2013 at 3:18 PM, Nicolas Burtnyk nico...@redshift3d.com wrote: Thanks Alok! That'a an excellent question. We don't currently have any official support for farm rendering. That being said, with a suitable render manager or some hand rolled scripts, I don't see why you couldn't have multiple machines working on different frames of an animation. And of course, we do plan on having more complete render farm support in the future. Your concern regarding the hardware configuration of render nodes is very valid. Redshift does require a GPU and we do not fall back on CPU in the absence of a suitable GPU. The performance gap is so large that it didn't really make sense for us at this stage to invest the time in making this kind of thing work (though we could entertain this possibility). Unfortunately, this does mean that some farms will not be good candidates for Redshift, particularly those in which adding a GPU to some or all of the nodes is not possible (e.g blades with no space in them). Keep in mind though that with the performance improvement factor provided by Redshift, you can get the performance of a farm with a dozen nodes from a single GPU-equipped node. We don't want to make any hard performance claims yet, but our internal tests are often showing 10x to 20x the performance of MR and VRay, sometimes more (on suitably complex scenes - super simple 10 seconds to render in MR stuff doesn't get 10x faster). So maybe you keep your existing farm for CPU renders and add a few GPU equipped nodes for Redshift. On Wed, Mar 13, 2013 at 11:45 AM, Alok alok.gan...@modusfx.comwrote: Congrats on your achievement, looking forward to see more of it. Just a quick question. For most of the render farm setups, usually the machines do not have high-end GPU's on them for the obvious reason that farm nodes never get user interaction and hence no need for realtime graphic intensive processing operations. Do you see that as a problem ? If yes then how would you address it. Does Red Shift turn to CPU for rendering in absence of the required GPU. ALOK GANDHI / chef directeur technique - lead technical director alok.gan...@modusfx.com T: *450 430-0010 x225 F: 450 430-0009 www.modusfx.com - MODUS FX 120 Rue Turgeon, Sainte-Therese (Quebec) CANADA J7E 3J1 Follow us on Facebook http://www.facebook.com/ModusFX Twitter https://twitter.com/Modusfx * On 13/03/2013 2:33 PM, Nicolas Burtnyk wrote: Yes - I'll try to make a video of that if I can get set up correctly for it. Note that this is 2 mins on a GTX 470 which is nothing special in terms of GPUs. You can expect significantly better times with a GTX 580 for example. I don't have official times for that card, but I'd guess under 1.5 minutes. These kinds of times really underscore the power of biased rendering. When you need to reduce noise, you have a lot more options than let's just throw a ton more samples at the whole thing. On Wed, Mar 13, 2013 at 11:28 AM, olivier jeannel olivier.jean...@noos.fr wrote: The classroom is *really* 2min render ? Congrats to you, sending a request :) Le 13/03/2013 19:18, Steven Caron a écrit : congrats to you and your team! i was wondering when we would see/hear about your work. it would be great to see a video demonstration of redshift in softimage. On Wed, Mar 13, 2013 at 11:12 AM, Nicolas Burtnyk nico
Re: Announcing Redshift - Biased GPU Renderer
Yeah, it very straightforward, you read the Particle 'Shape' attribute. Then compare that value against the ICEShapeType enum, if the ICEShapeType is Reference, then you have a Particle Instance of a object in the scene. You can then take that value and get the actual Object by various means, one of them being thru Dictionary.GetObject(). Once you have the object, you can read it's Type value to determine what kind of object (model, polymesh, light, etc.) is being instanced, and then go from there.
Re: SI 2014 sneak peek
Best explanation of this tool yet. Thanks Steven. On Thu, Feb 28, 2013 at 2:00 PM, Steven Caron car...@gmail.com wrote: 'editing' is only one aspect of this tool. the idea is you can now view time in the scene out of sequence from which you are normally used to. you have two people in a car, driving, arguing. you have 2 cameras, which you cut back and forth from. sometimes you want to show the reaction of the passengers face to something the driver is saying. thing is these happen at the same time, but you want to see them one after the other. the sequencer will allow you as an animator see the two shots in context of each other. softimage will play the scene forward, then jump back, switch the camera, and play it again. now you want to add another shot, where the passenger is holding a weapon down by their side of the seat and just as the passenger reacts to the driver's comment, we get a slow mo shot of their hand raising a gun to the driver's head. the sequencer can handle the slow motion too. this works really well for mocap performances because the actor's are doing all of this on the stage in realtime. when you get the data back you can decide how to 'shoot' it after the fact. no more constraining a camera to 3 cameras and animating the blend weights (which breaks if your camera's frames overlap), having to extend your scene frame range to account for three shots in one scene file, and you can do re times/time warps with very little effort.
Re: Exporting animated weightmap
Adding native image i/o via ICE would've been sooo nice in SI 2014. On Wed, Feb 27, 2013 at 2:01 PM, Steven Caron car...@gmail.com wrote: ah, carry on :) On Wed, Feb 27, 2013 at 10:58 AM, Philip Melancon philip.melan...@modusfx.com wrote: We need to transfer the result of some maps (compression, collision, etc) to maya for some various effects as our FX department is mainly maya-based and everything else is done on soft. On 27/02/2013 1:31 PM, Steven Caron wrote: do you want to edit the image sequence in some way? why use images? On Wed, Feb 27, 2013 at 9:35 AM, Philip Melancon philip.melan...@modusfx.com wrote: Thank you all, I'll try and find that compound Eric mentioned. If that doesn't work I'll have a look at the map lookup technique. On 27/02/2013 11:26 AM, Leonard Koch wrote: And if you then want to render multiple frames with the render map, this script I wrote a while ago is helpful. It's attached. On Wed, Feb 27, 2013 at 5:23 PM, Alan Fregtman alan.fregt...@gmail.com wrote: Hey Phil, I assume it's probably on a character or something with UVs? If you have UVs: You could switch over to mentalray, apply a constant shader on your mesh, get a Map Lookup Color node to read the weightmap as a black and white value and do a RenderMap over time. You can do this with one of these scripts: http://www.sajjadamjad.com/plugins.html#Mapify http://www.si-community.com/community/viewtopic.php?f=29t=1607 If you don't have UVs then I assume it's a flat surface or something? In that case you could again use the Map Lookup Color node on a constant still, but aim an orthographic camera at it nice and flat and render that out normally. Cheers, -- Alan ps: Say hi to the other modusians for me. ;) On Wed, Feb 27, 2013 at 10:50 AM, Philip Melancon philip.melan...@modusfx.com wrote: Hello list, I was wondering if any of you knew of a convenient way of exporting an animated weightmap from an ice tree to an image sequence? I think I remember seeing something about this a while back but I can't seem to remember when and where. Thanks for any help you can provide! No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.2238 / Virus Database: 2641/5635 - Release Date: 02/26/13 -- Philip Melancon Lead crowd TD Modus FX No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.2238 / Virus Database: 2641/5635 - Release Date: 02/26/13 -- Philip Melancon Lead crowd TD Modus FX
