Re: Camera distance to an object

[Emilio Hernandez]

Cool I will try that thanks a lot!




2013/3/29 Andy Moorer 

> You then need a "distance to plane" calculation... the distance from the
> camera to null is the hypotenuse of a right triangle. The angle of that
> line versus the z axis of the camera then gives you enough information to
> determine the distance to the camera plane the null is on.
>
> cos(theta)=a/h where you want the length of the adjacent side (a)...
>
> So the value you seek is cos(angle)*distance to null.
>
>
>
>
> On Fri, Mar 29, 2013 at 3:38 AM, Emilio Hernandez wrote:
>
>> Yes it's working with the null centered.  But what if I want the focus on
>> some moving object that is not always in the center of the camera and
>> coming near?  It is like a follow focus rig.
>>
>>
>>
>>
>> 2013/3/29 Ben Davis 
>>
>>> Makes sense, thanks Tim!
>>>
>>> That means that the info from the "Distance to Output Camera" is doing
>>> exactly what you need Emilio, since when centered the ICETree info matches
>>> perfectly.
>>>
>>> --
>>> Ben Davis
>>>
>>> www.moondog-animation.com
>>>
>>> +33 6 88 48 54 50
>>>
>>>
>>> On Fri, Mar 29, 2013 at 10:31 AM, Tim Leydecker wrote:
>>>
 Hey Ben,

 the farther offset the null is off center to the center of the camera
 view
 the more "off" the DOF would be because the DOF effect is sets in
 respect
 to the viewplane of the camera and it would take some Pythagorean
 theorem
 (http://en.wikipedia.org/wiki/**Hypotenuse)
 to get the desired major cathetus,
 which is the Distance between Camera Center and a "Plane" from the
 shorter
 cathetus.

 To avoid that, it愀 easier to constraint the camera to "look at" the
 null,
 then the hypothenuse "snaps back into" the longer cathetus and there is
 no offset anymore to worry about.

 Cheers,

 tim


 On 29.03.2013 10:06, Ben Davis wrote:

> It looks like "Distance to Output Camera" from the viewport options is
> spitting out the info from a plane in front of the camera based on the
> distance from the null if it were in the center of your camera's view.
> If
> your null is centered, the values are the same from the ICETree and the
> viewport info.
>
> The ICE info from the "Get Distance Between" is exactly the distance
> from
> center to center (global.kine to global.kine). I don't see a problem
> with
> using the info from ICE to feed into your DOF, you're probably going
> to get
> a more precise focus placement (I'll accept being refuted by the
> photographers out there :)
>
> Hope that helps!
>
> Ben
>
> --
> Ben Davis
>
> www.moondog-animation.com
>
> +33 6 88 48 54 50
>
>
> On Fri, Mar 29, 2013 at 9:20 AM, Emilio Hernandez 
> wrote:
>
>  Hello I am trying to rig the camera DOF so I can attach the distance
>> to a
>> null.  I am the ICE distance between node.  But when I turn on the
>> distance
>> to output camera from the viewer, it gives me a different result.
>>
>> So the Distance to output camera from the viewport options is
>> different
>> than the Distance between node in the ICE tree using the
>> kine.global.pos
>> from the camera and the null.
>>
>> I will appreciate any help on this issue.
>>
>> --
>>
>>
>>
>
>>>
>>
>>
>> --
>>
>>
>


--

Re: set raycast direction with a Null?

[Andy Moorer]

(opens personal toolbox) here you go m8...




On Fri, Mar 29, 2013 at 6:54 PM, Sam  wrote:

> I have a null I’m using to raycast onto a mesh and it working pretty good,
> but I want to be able to adjust the direction by rotating the null and I
> can’t seem to get this to work. There is a direction to rotation node, but
> there doesn’t seem to be a rotation to direction node. Any help is
> appreciated.
>


Vector from Arrow Direction.xsicompound
Description: Binary data

RE: set raycast direction with a Null?

[Matt Lind]

All you need to do is pluck an axis out of the transform and use that as your 
direction vector.  You can do that with the matrix to 3D vector converters.

Matt



From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Sam
Sent: Friday, March 29, 2013 6:55 PM
To: softimage@listproc.autodesk.com
Subject: set raycast direction with a Null?

I have a null I'm using to raycast onto a mesh and it working pretty good, but 
I want to be able to adjust the direction by rotating the null and I can't seem 
to get this to work. There is a direction to rotation node, but there doesn't 
seem to be a rotation to direction node. Any help is appreciated.

set raycast direction with a Null?

[Sam]

I have a null I'm using to raycast onto a mesh and it working pretty good,
but I want to be able to adjust the direction by rotating the null and I
can't seem to get this to work. There is a direction to rotation node, but
there doesn't seem to be a rotation to direction node. Any help is
appreciated.

Re: Camera distance to an object

[Andy Moorer]

You then need a "distance to plane" calculation... the distance from the
camera to null is the hypotenuse of a right triangle. The angle of that
line versus the z axis of the camera then gives you enough information to
determine the distance to the camera plane the null is on.

cos(theta)=a/h where you want the length of the adjacent side (a)...

So the value you seek is cos(angle)*distance to null.




On Fri, Mar 29, 2013 at 3:38 AM, Emilio Hernandez  wrote:

> Yes it's working with the null centered.  But what if I want the focus on
> some moving object that is not always in the center of the camera and
> coming near?  It is like a follow focus rig.
>
>
>
>
> 2013/3/29 Ben Davis 
>
>> Makes sense, thanks Tim!
>>
>> That means that the info from the "Distance to Output Camera" is doing
>> exactly what you need Emilio, since when centered the ICETree info matches
>> perfectly.
>>
>> --
>> Ben Davis
>>
>> www.moondog-animation.com
>>
>> +33 6 88 48 54 50
>>
>>
>> On Fri, Mar 29, 2013 at 10:31 AM, Tim Leydecker  wrote:
>>
>>> Hey Ben,
>>>
>>> the farther offset the null is off center to the center of the camera
>>> view
>>> the more "off" the DOF would be because the DOF effect is sets in respect
>>> to the viewplane of the camera and it would take some Pythagorean theorem
>>> (http://en.wikipedia.org/wiki/**Hypotenuse)
>>> to get the desired major cathetus,
>>> which is the Distance between Camera Center and a "Plane" from the
>>> shorter
>>> cathetus.
>>>
>>> To avoid that, it愀 easier to constraint the camera to "look at" the null,
>>> then the hypothenuse "snaps back into" the longer cathetus and there is
>>> no offset anymore to worry about.
>>>
>>> Cheers,
>>>
>>> tim
>>>
>>>
>>> On 29.03.2013 10:06, Ben Davis wrote:
>>>
 It looks like "Distance to Output Camera" from the viewport options is
 spitting out the info from a plane in front of the camera based on the
 distance from the null if it were in the center of your camera's view.
 If
 your null is centered, the values are the same from the ICETree and the
 viewport info.

 The ICE info from the "Get Distance Between" is exactly the distance
 from
 center to center (global.kine to global.kine). I don't see a problem
 with
 using the info from ICE to feed into your DOF, you're probably going to
 get
 a more precise focus placement (I'll accept being refuted by the
 photographers out there :)

 Hope that helps!

 Ben

 --
 Ben Davis

 www.moondog-animation.com

 +33 6 88 48 54 50


 On Fri, Mar 29, 2013 at 9:20 AM, Emilio Hernandez 
 wrote:

  Hello I am trying to rig the camera DOF so I can attach the distance
> to a
> null.  I am the ICE distance between node.  But when I turn on the
> distance
> to output camera from the viewer, it gives me a different result.
>
> So the Distance to output camera from the viewport options is different
> than the Distance between node in the ICE tree using the
> kine.global.pos
> from the camera and the null.
>
> I will appreciate any help on this issue.
>
> --
>
>
>

>>
>
>
> --
>
>

Re: Softimage 2013/2014 Irradiance Particles - IP Optimize still single threaded?

[Christopher]

Sorry I didn't catch your 
answer even though you were screaming it, your reply could have been a 
documentary on renders I got lost in it :-)
I've been testing 3Delight, from their demo, I like how it renders, but 
is there any hipcup when it converts Mental Ray shaders to Renderman, I 
was told converting can sometimes be a bad thing. Too bad there isn't 
some renderman nodes in Softimage :)  
This is a tough choice, redshift makes unbelievable rendered images, 
with the right knowledge you can turn out nice from Mental Ray just as 
well.  I look forward to the test scenes.  If keyshot is good at stills,
 and 3Delight is good at animation, does that make Vray a blend of the 
two ?

Christopher


   	   
   	Octavian Ureche  
  Friday, March 29,
 2013 7:14 PM
  Well, i thought i made it 
pretty obvious given the vray preaching i just did. If not here it is: 
vray.Also, if you're not into animation, and more on the still 
render side, you should definitely check out keyshot. Modo has a very 
good renderer as well, but unfortunately i still haven't managed to get 
used to its interface and shading system. I find them clunky, but that's
 just personal bias. 3delight is also an interesting choice if you're 
doing animation with tons of displacement, hair, dof and motionblur, 
though i don't know what has been happening lately on its development 
front. It used to have a free license for personal use, but i can't 
recall if the offer was for xsi or maya.

But with the xsi platform in mind, i think redshift looks really 
promising. Cpu's are expensive like hell. This could free up a 
freelancer's budget if priced accordingly, and integrated correctly.

PS. I'll share that vray vs arnold displacement test scene 
this weekend. See if we can get any real data.Night,

  
   	   
   	Christopher  
  Friday, March 29,
 2013 6:41 PM
  



Thank you that was very 
informative :)  What render do you recommend to have besides Mental Ray ?





Christopher












  
   	   
   	Octavian Ureche  
  Friday, March 29,
 2013 3:35 PM
  Hey Christopher,I 
think i can give my 2 cents on maxwell, as i have been on its betaas
 well a few years back. This is from what was going on then. Icannot
 say anything about the current state of the engine as i havenot 
touched it since.Purely from a rendering standpoint, maxwell felt 
slow, first andforemost because it is an unbiased engine, and it 
does not cheat itssolution. That means in order to get rid of the 
sampling it needs todo a ton of passes to get an accurate 
convergence. What that meant forme, as an individual, was that 
animation was out of the questionunless i was willing to work with a
 grainy image or if i chose to waita long time for the frames to be 
rendered.Most people these days rely on farms to render with maxwell
 in ananimation environment (rendernet.se comes to mind).This 
was the low side of it, and i hear it is quite similar to arnoldfrom
 this standpoint (good quality takes more samples which in turntakes
 a longer time to achieve). This is because both engines do notprecompute
 or cache anything. Brute force is the word here, whereasvray, even 
if it does brute force well, it has a ton of other choicesto "cheat"
 its way through, resulting in a faster rendertime, which inturn, 
unfortunately, requires greater knowledge from the user.On the 
upside, the shading system was nice, had the usual ubershaderapproach,
 tons of shaders available in the community. Did not uselight 
sources, but instead turned objects into emitters using aspecial 
shader. That meant the shadows and everything else looked veryrealistic.
 Its preview system was way ahead of anything at that timein terms 
of seeing the final look of the image, in the first pass, soyou 
could get a very good idea if you needed to adjust things beforewaiting
 for 2 hours. Now this has been updated to the maxwell "fire"engine.
 But most renderers today give you this (modo's preview orvray's 
light cache come to mind). By far the most useful feature ofthe 
engine for me, was its mxi image format (similar to a raw file),which
 stored lighting information from all the light sources. Thatmeant 
if you had screwed up your exposure, lights etc, you could fixeverything
 afterwards, and i don't mean brightness/contrast fix. Youcould dial
 the lights in and out, change their intensity, etc, andeverything 
would update realtime in it's "image editor". I hear nowthey have a 
nuke plugin for this.Worked for sequences of frames as well, and was
 a lifesaver.I remember this one time i had an interior to render 
for a client, andit had around 50 lights total.The guy did a 
dozen variations, changing colors and turning lights onand off. Had 
it not been for this feature,i would have been rendering a week on 
the project.With it, i just waited a couple of hours, and then did a
 dozenvariations in half an hour from the same render.Final 
thing i'd like to point out, was that its xsi integration wasnot 
that goo

Re: Softimage 2013/2014 Irradiance Particles - IP Optimize still single threaded?

[Octavian Ureche]

Well, i thought i made it pretty obvious given the vray preaching i just
did. If not here it is: vray.
Also, if you're not into animation, and more on the still render side, you
should definitely check out keyshot. Modo has a very good renderer as well,
but unfortunately i still haven't managed to get used to its interface and
shading system. I find them clunky, but that's just personal bias. 3delight
is also an interesting choice if you're doing animation with tons of
displacement, hair, dof and motionblur, though i don't know what has been
happening lately on its development front. It used to have a free license
for personal use, but i can't recall if the offer was for xsi or maya.
But with the xsi platform in mind, i think redshift looks really promising.
Cpu's are expensive like hell. This could free up a freelancer's budget if
priced accordingly, and integrated correctly.

PS. I'll share that vray vs arnold displacement test scene this weekend.
See if we can get any real data.

Night,

Re: Softimage 2013/2014 Irradiance Particles - IP Optimize still single threaded?

[Christopher]

Thank you that was very 
informative :)  What render do you recommend to have besides Mental Ray ?





Christopher





 	   
   	Octavian Ureche  
  Friday, March 29,
 2013 3:35 PM
  Hey Christopher,I 
think i can give my 2 cents on maxwell, as i have been on its betaas
 well a few years back. This is from what was going on then. Icannot
 say anything about the current state of the engine as i havenot 
touched it since.Purely from a rendering standpoint, maxwell felt 
slow, first andforemost because it is an unbiased engine, and it 
does not cheat itssolution. That means in order to get rid of the 
sampling it needs todo a ton of passes to get an accurate 
convergence. What that meant forme, as an individual, was that 
animation was out of the questionunless i was willing to work with a
 grainy image or if i chose to waita long time for the frames to be 
rendered.Most people these days rely on farms to render with maxwell
 in ananimation environment (rendernet.se comes to mind).This 
was the low side of it, and i hear it is quite similar to arnoldfrom
 this standpoint (good quality takes more samples which in turntakes
 a longer time to achieve). This is because both engines do notprecompute


 or cache anything. Brute force is the word here, whereasvray, even 
if it does brute force well, it has a ton of other choicesto "cheat"
 its way through, resulting in a faster rendertime, which inturn, 
unfortunately, requires greater knowledge from the user.On the 
upside, the shading system was nice, had the usual ubershaderapproach,


 tons of shaders available in the community. Did not uselight 
sources, but instead turned objects into emitters using aspecial 
shader. That meant the shadows and everything else looked veryrealistic.


 Its preview system was way ahead of anything at that timein terms 
of seeing the final look of the image, in the first pass, soyou 
could get a very good idea if you needed to adjust things beforewaiting


 for 2 hours. Now this has been updated to the maxwell "fire"engine.
 But most renderers today give you this (modo's preview orvray's 
light cache come to mind). By far the most useful feature ofthe 
engine for me, was its mxi image format (similar to a raw file),which


 stored lighting information from all the light sources. Thatmeant 
if you had screwed up your exposure, lights etc, you could fixeverything


 afterwards, and i don't mean brightness/contrast fix. Youcould dial
 the lights in and out, change their intensity, etc, andeverything 
would update realtime in it's "image editor". I hear nowthey have a 
nuke plugin for this.Worked for sequences of frames as well, and was
 a lifesaver.I remember this one time i had an interior to render 
for a client, andit had around 50 lights total.The guy did a 
dozen variations, changing colors and turning lights onand off. Had 
it not been for this feature,i would have been rendering a week on 
the project.With it, i just waited a couple of hours, and then did a
 dozenvariations in half an hour from the same render.Final 
thing i'd like to point out, was that its xsi integration wasnot 
that good nor stable back then.Maybe now things have changed, but 
last i looked, it was pretty muchthe same workflow.Cheers,O
   	   
   	Octavian Ureche  
  Friday, March 29,
 2013 3:12 PM
  Hey Steven,No


 i have not directly. But having looked at arnold videos on 
the net, with computer specs given, i can state that from what i have 
seen, arnold is close to mantra in terms of displacement speed (which i 
have used). So it is close to a reyes renderer in that sense. Again, 
this is comparing what i know to what i have seen (but you can't really 
cheat rendering speed).

Vray is definitely not that fast.

  
   	   
   	Christopher  
  Friday, March 29,
 2013 2:44 PM
  



What about Maxwell, which 
render has lots it's potential ?





Christopher


Sent from my Desktop ;-)









  
   	   
   	Steven Caron  
  Friday, March 29,
 2013 2:19 PM
  you state that 
like its common knowledge... i just wanted to know if you have compared 
arnold's displacement to vray's? i haven't and would like to know.

  
   	   
   	Octavian Ureche  
  Friday, March 29,
 2013 2:06 PM
  Displacement is fast, but 
obviously not as fast as a reyes renderer or arnold. Hair rendering has 
also improved lately, and motionblur and dof are okay. Nowhere near 
arnold but way faster than mental ray. The thing to note about vray is 
that it requires a bit more knowledge about its inner workings to be 
able to get the most of it. But it's an extremely stable and reliable 
renderer. Also on the plus side it handles interiors extremely well, and
 its ibl tools are stellar.

Don't get me wrong, i am not afilliated with chaos group in any way even
 though i was on the beta. It's just my personal view on the engine. I'm
 sure arnold's  algorithms will improve with time, and when it starts 
being less prohibitive , vray will have quite some heavy competitio

Re: ICE Topo Clone from group of objects onto Particles?

[Ahmidou Lyazidi]

I can see the attachment too!

---
Ahmidou Lyazidi
Director | TD | CG artist
http://vimeo.com/ahmidou/videos


2013/3/29 Dan Yargici 

> I can see them (Gmail)
>
> DAN
>
>
> On Fri, Mar 29, 2013 at 1:32 PM, Stephen Blair wrote:
>
>> Hi Gray
>> I don't see any attachments.
>> This happened last time you posted a screenshot too. I couldn't find the
>> attachments
>>
>>
>>
>> On 28/03/2013 6:46 PM, Grahame Fuller wrote:
>>
>>> Do these compounds help? I've posted before but for some reason the
>>> attachments don't seem to make it into the archives.
>>>
>>> They were designed to copy particle instances to real topology, but
>>> obviously you don't actually need instances but just an integer for the
>>> object index in the group.
>>>
>>> Usage notes:
>>>
>>> To use, put Convert Instances to Mesh in an ICE tree on an empty mesh.
>>> It works only with the "self" object. You also need to store the shape
>>> index on the point cloud and reference it in the compound's ppg. To
>>> transfer attributes, attach one of the Transfer compounds to the Execute
>>> port - there's one for each component type.
>>>
>>> If you transfer the MaterialIDs, then you can use the Copy Materials
>>> checkbox. This works only if all objects in the group have identical
>>> Materials arrays.
>>>
>>> The transfer is based on finding locations on the group geometry, so
>>> it's best to move the instance masters apart if they overlap.
>>>
>>> It uses the 2013 version of Build Array from Set which supports
>>> topology-type attributes. To use it with Softimage v2012, you'll need to
>>> replace it with Build Array from Per Point Data.
>>>
>>> gray
>>>
>>> From: 
>>> softimage-bounces@listproc.**autodesk.com[mailto:
>>> softimage-bounces@**listproc.autodesk.com]
>>> On Behalf Of Eric Thivierge
>>> Sent: Thursday, March 28, 2013 06:30 PM
>>> To: softimage@listproc.autodesk.**com 
>>> Subject: Re: ICE Topo Clone from group of objects onto Particles?
>>>
>>>
>>> Thanks but I need it as actual geometry using ice topology
>>> On Mar 28, 2013 6:09 PM, "Daryl Dunlap" >> mailto:twinsnakes...@gmail.com**>> wrote:
>>> Hey Eric,
>>>
>>> There's an example in the Docs for just that scenario.
>>>
>>> http://download.autodesk.com/**global/docs/softimage2013/en_**
>>> us/userguide/index.html?url=**files/ipart_instances_**
>>> UsingGroupsofMasterObjects.**htm,topicNumber=d30e291285
>>>
>>> On Thu, Mar 28, 2013 at 6:03 PM, Eric Thivierge >> > wrote:
>>> Trying to clone a group of meshes and place them at particle positions
>>> from a cloud using ICE Topo. Is there a way to get any of the built in
>>> compounds to do this? Not seeing any compounds or sample scenes doing this.
>>>
>>> So to review I have 5 meshes in a group and a particle cloud. I want to
>>> randomly get a mesh out of the group and stick it where a particle is.
>>>
>>> --**--
>>> Eric Thivierge
>>> http://www.ethivierge.com
>>>
>>>
>>
>

Re: Softimage 2014

[Sebastien Sterling]

well then sit back and watch Houdini cream you :P


On 29 March 2013 21:21, Jason S  wrote:

> **
> No we are now (officially) Visual Effects and Animation Software :)
>
>
>
> On 29/03/2013 1:01 PM, olivier jeannel wrote:
>
> Stop asking things for modeling and texturing ! We're a particle system
> for God Sake !
>
> :D
>
>
> Le 29/03/2013 12:15, Simon Reeves a écrit :
>
> Diving in a bit here so apologies if I missed it, but you can freeze uv's
> and keep the projection, and unfreeze it at any time. There's a little
> 'freeze' button in one of the texture properties somewhere.
> Ill look where it is exactly when I'm infront of soft
>
> Simon Reeves
> VFX Artist
> London, UK
>
> On 29 Mar 2013, at 06:42, Szabolcs Matefy  wrote:
>
>   Shit hits the fan, when you want to to have sculpt like deformation in
> XSI. Unfortunately the current system doesn’t let you build up your strokes
> properly, due to the weightmap limitation. What I think, that each “stroke”
> should have its own weight map, but that would slaughter the performance.
> The graphite toolset has quite nice things, but our max artist hate it,
> it’s nowhere close to the original polyboost feature set.
>
>
>
> Maybe, texture should have its own history stack? And an additional Freeze
> T button to freeze texturing only? Anyway, while a texture operator is
> live, I’d sometimes have it sit on the top of the stack, so the Texture
> History is a good idea.
>
>
>
> I tried to recreate for example, the DPK Paint Deform (
> http://dpk.stargrav.com/pafiledb/pafiledb.php?action=file&id=32) with
> ICE, and more or less succeeded. Unfortunately the buildup is missing (when
> your strokes are accumulating, causing the increased effect. Maya’s artisan
> treats it pretty well. And since I do all of my modeling with my Wacom pen,
> I’d be happy with a proper sculpting tool. And not to mention, the ability
> to disable the weightmap display during sculpting…Seeing the model in
> constant shading with the weight map is not really help in deformation.
>
>
>
>
>
> My 2 cents
>
>
>
> Szabolcs
>
>
>
> *From:* softimage-boun...@listproc.autodesk.com [
> mailto:softimage-boun...@listproc.autodesk.com]
> *On Behalf Of *Sebastien Sterling
> *Sent:* Friday, March 29, 2013 12:31 AM
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: Softimage 2014
>
>
>
> I agree with matt, if only to add a new tab like m freeze, but which would
> preserve texture,
>
> the tool you are talking about in max is called paint deformation, and it
> is at the bottom of the edit poly operation menu, you can push pull relax,
> its basically like artisan in maya.
>
> On 28 March 2013 23:08, Matt Lind  wrote:
>
> I think the point is that many of these features are not readily available
> out of the box.  We have to write the tools ourselves and there are many
> blockades to getting the job done.
>
>
>
> I have the ICE compound Guillame LaForge sent out last year, but it’s a
> bit hit and miss.  We’re not supporting ICE in our pipeline yet due to
> instability when using ICE on reference models.  80% of our content is
> referenced models.  I cannot let ICE compounds run amok in scenes that
> become referenced models and are reused in hundreds of other scenes.  We
> don’t have the bandwidth to manage such a situation.
>
>
>
> Paint – Softimage is light years behind everybody else.  That is the
> point.  Their animation-first mindset has been an obstacle to developing a
> pipeline as the parts we need most are modeling and texturing.  Animation
> is nice, but it too lacks a lot of tools and workflows expected out of the
> box.
>
>
>
> Max does have tools to modify topology as our character artist showed me
> the tools a year or so ago spurring me to request the same from Softimage.
> They had the ability to pinch and pull, displace, as well as cut into the
> mesh almost like Zbrush.  ZBrush was definitely more robust, but what Max
> offered was enough for what we needed to do.  I’m not a Max user, so don’t
> ask me the names of the tools.  The best I can remember was something to do
> with a graphite toolset and the brush has the ability to have operators
> assigned to it so they could be painted on meshes.  It was intuitive –
> something which softimage’s paint workflow is anything but.
>
>
> Matt
>
>
>
>
>
>
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Ahmidou Lyazidi
> *Sent:* Wednesday, March 27, 2013 4:32 PM
>
>
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: Softimage 2014
>
>
>
> Hi Matt, as you moved to 2013 lately, there might be workarounds for some
> of you problems.
>
> *
> Preserve UVs*: I think it's not publicly available, but piotrek did a
> swim UVs for explicit using the custom tool SDK, so it's doable.
>
> *Pain*t: A Maya Artisan like paint tool is also possible, I have an
> unfinished one, it's only doing push and smooth, but working, I also never
> found the time to implement undo/redo.
>
> Als

Re: Softimage 2013/2014 Irradiance Particles - IP Optimize still single threaded?

[Steven Caron]

just do it! start a new thread. provide the vray side with whatever scene
and/or parameters and i am sure someone with an arnold license will step
up. i wont promise i can but if i find the time i might contribute an
arnold test.


On Fri, Mar 29, 2013 at 12:46 PM, Octavian Ureche  wrote:
>
> If anyone is up for it, send me a mail. I have a couple of days to
> kill until the next gig.
>

Re: Softimage 2014

[Jason S]

No we are now (officially) Visual Effects and Animation Software :)


On 29/03/2013 1:01 PM, olivier jeannel wrote:
Stop asking things for modeling and texturing ! We're a particle 
system for God Sake !


:D


Le 29/03/2013 12:15, Simon Reeves a écrit :
Diving in a bit here so apologies if I missed it, but you can freeze 
uv's and keep the projection, and unfreeze it at any time. There's a 
little 'freeze' button in one of the texture properties somewhere.

Ill look where it is exactly when I'm infront of soft

Simon Reeves
VFX Artist
London, UK

On 29 Mar 2013, at 06:42, Szabolcs Matefy > wrote:


Shit hits the fan, when you want to to have sculpt like deformation 
in XSI. Unfortunately the current system doesn’t let you build up 
your strokes properly, due to the weightmap limitation. What I 
think, that each “stroke” should have its own weight map, but that 
would slaughter the performance. The graphite toolset has quite nice 
things, but our max artist hate it, it’s nowhere close to the 
original polyboost feature set.


Maybe, texture should have its own history stack? And an additional 
Freeze T button to freeze texturing only? Anyway, while a texture 
operator is live, I’d sometimes have it sit on the top of the stack, 
so the Texture History is a good idea.


I tried to recreate for example, the DPK Paint Deform 
(http://dpk.stargrav.com/pafiledb/pafiledb.php?action=file&id=32 
) 
with ICE, and more or less succeeded. Unfortunately the buildup is 
missing (when your strokes are accumulating, causing the increased 
effect. Maya’s artisan treats it pretty well. And since I do all of 
my modeling with my Wacom pen, I’d be happy with a proper sculpting 
tool. And not to mention, the ability to disable the weightmap 
display during sculpting…Seeing the model in constant shading with 
the weight map is not really help in deformation.


My 2 cents

Szabolcs

*From:* softimage-boun...@listproc.autodesk.com 
 
[mailto:softimage-boun...@listproc.autodesk.com] *On Behalf Of 
*Sebastien Sterling

*Sent:* Friday, March 29, 2013 12:31 AM
*To:* softimage@listproc.autodesk.com 


*Subject:* Re: Softimage 2014

I agree with matt, if only to add a new tab like m freeze, but which 
would preserve texture,


the tool you are talking about in max is called paint deformation, 
and it is at the bottom of the edit poly operation menu, you can 
push pull relax, its basically like artisan in maya.


On 28 March 2013 23:08, Matt Lind > wrote:


I think the point is that many of these features are not readily 
available out of the box.  We have to write the tools ourselves and 
there are many blockades to getting the job done.


I have the ICE compound Guillame LaForge sent out last year, but 
it’s a bit hit and miss.  We’re not supporting ICE in our pipeline 
yet due to instability when using ICE on reference models.  80% of 
our content is referenced models.  I cannot let ICE compounds run 
amok in scenes that become referenced models and are reused in 
hundreds of other scenes.  We don’t have the bandwidth to manage 
such a situation.


Paint – Softimage is light years behind everybody else.  That is the 
point.  Their animation-first mindset has been an obstacle to 
developing a pipeline as the parts we need most are modeling and 
texturing.  Animation is nice, but it too lacks a lot of tools and 
workflows expected out of the box.


Max does have tools to modify topology as our character artist 
showed me the tools a year or so ago spurring me to request the same 
from Softimage.  They had the ability to pinch and pull, displace, 
as well as cut into the mesh almost like Zbrush.  ZBrush was 
definitely more robust, but what Max offered was enough for what we 
needed to do.  I’m not a Max user, so don’t ask me the names of the 
tools.  The best I can remember was something to do with a graphite 
toolset and the brush has the ability to have operators assigned to 
it so they could be painted on meshes.  It was intuitive – something 
which softimage’s paint workflow is anything but.



Matt

*From:* softimage-boun...@listproc.autodesk.com 
 
[mailto:softimage-boun...@listproc.autodesk.com 
] *On Behalf Of 
*Ahmidou Lyazidi

*Sent:* Wednesday, March 27, 2013 4:32 PM


*To:* softimage@listproc.autodesk.com 


*Subject:* Re: Softimage 2014

Hi Matt, as you moved to 2013 lately, there might be workarounds for 
some of you problems.


*
Preserve UVs*: I think it's not publicly available, but piotrek did 
a swim UVs for explicit using the custom tool SDK, so it's doable.


*Pain*t: A Maya Artisan like paint tool is also possible, I have an 
unfinished one, it's only doing push and sm

RE: Softimage 2014

[Matt Lind]

The issue isn't about whether history is available or not.  It's about whether 
the functions we need to use are usable at all times and in all contexts.  
Softimage texture workflow only works in specific contexts.  That is the issue. 
 Softimage has a construction history which is useful for some operations such 
as enveloping or putting modeling operations in the animation construction 
marker, but those same workflows can also cause problems as it does with 
texture operations in conjunction with modeling.

As for specific examples in Modo's favor:

1) UV unfolding and pinning I've been screaming about the past few years.  
Softimage botched that one.  Modo's pins allow the rest of the unpinned texture 
space to 'solve' in the unfolding process.  It's also interactive.   I 
specifically pointed out Modo in the feature requests I submitted, but whoever 
implemented the pinning feature obviously didn't read the notes.

Modo's tools can be applied at any time and in any order.  Softimage's cannot.  
That alone is HUGE.  Softimage lacks basic tools such as splitting and merging 
UVs along selected boundaries, aligning islands, and other expected tools for 
working with pelts and texture spaces in general.  Softimage has the low level 
features such as tearing mode, but you have to work really hard to select the 
parts of the texture space to rip apart and isolate as desired.  Artists often 
think in terms of polygon boundaries and tearing along boundaries between body 
parts such as separating the hands from the arms, or inserting a cut line along 
the sides of fingers so they splay nicely for unfolding and painting.  Pinning 
and movable pins is a big part of this workflow.  It can be done in Softimage, 
but it takes significantly more effort - especially with the botched 
implementation of pinning and rigid black box method of unfold's 
implementation.  Tools work nicely together in Modo.  The capabilities are 
there in Softimage, but tools don't play together as they should, and many 
expected tools are not implemented correctly or exposed to the end user.


2) Symmetrical modeling such as wrists.

It's often necessary to resize or reshape local areas of the character per art 
direction.  In the case of wrists, sometimes they are too fat or too skinny, 
need to be lengthened or shortened, etc.  This is a difficult task in Softimage 
as the symmetry transforms only work on points.  Since Softimage computes 
reference frames on point selections and doesn't give the artist much input in 
orienting reference frames, it's a bit of teeth pulling experience to make 
these simple adjustments as local axes don't necessarily align along the limb's 
length and perpendicular to the width as desired.  Even if the reference frames 
(centers) are aligned, Softimage doesn't interpret the rotations properly 
across the axis of symmetry preferring to handle the case in object or global 
space instead of COG or local.  I have reported this issue more than once.

Softimage scaling defaults to prevent shearing by scaling on the local axes.  
Sometimes modelers need the global axis, but as you can clearly see on the MCP, 
global is not an option for scaling.

3) Another example is locking subcomponents in the topology to prevent 
accidental editing.  This is critical for working with objects that have to 
join seamlessly with other objects.  Artists can lock the points (and normal, 
and UVs) on the boundary edge so they are not accidentally moved but still 
allow them to model with reckless abandon on the interior of the object to be 
quick and efficient.

Specific example - faces for bodies.  Our characters have customizable faces 
which are plug and play like a Mr. Potato Head doll.  If the customer wants the 
skinny face, then the skinny face is plugged into the body.  If the customer 
wants the fat face, then the fat face is plugged into the body.  For this 
system to work, all the available faces must have the same contours so they 
plug into the head seamlessly without cracks.  When our library consists of 
500+ faces and only one person to do that work, the artist needs the comfort of 
being able to work quickly without fear of destroying the asset or making it 
incompatible with other assets (body) it needs to work with.  For faces it 
means locking the contours so they cannot be edited.  Modo provides this 
functionality.  Softimage does not.  Softimage locks the entire topology of 
none of the topology.  Even if custom operators are written to do the job, they 
are prone to be removed the next time the artist clicks 'freeze' or 'freeze M'. 
 We've had this very discussion already.


I have already submitted and described the above items in beta cycles and we 
had discussions about them.  I'm really starting to wonder if it was a waste of 
time.

I'm not a Modo user, but our character artists repeatedly come to me for basic 
things Softimage should handle, but doesn't.  They want to use Softimage as it 
would reduce

Re: Softimage 2013/2014 Irradiance Particles - IP Optimize still single threaded?

[Octavian Ureche]

Hey Steven,

You are right. Arnold is pretty much looked upon as the magical
solution to everyone's rendering problems (i know because i certainly
think it too when sh hits the fan with what i use), which tends to
become annoying.
But i'd love to see a displacement test of both. Unfortunately there's
no trial version of arnold yet.
What i'm thinking is maybe i could find someone on this list that has
a similar proc as mine (i7 3770k 3.5 ghz),
and we could share a similar scene with the same model and
displacement map, just to get an idea of rendertimes and memory
footprint at the same res.

If anyone is up for it, send me a mail. I have a couple of days to
kill until the next gig.

Re: Softimage 2013/2014 Irradiance Particles - IP Optimize still single threaded?

[Octavian Ureche]

Hey Christopher,

I think i can give my 2 cents on maxwell, as i have been on its beta
as well a few years back. This is from what was going on then. I
cannot say anything about the current state of the engine as i have
not touched it since.
Purely from a rendering standpoint, maxwell felt slow, first and
foremost because it is an unbiased engine, and it does not cheat its
solution. That means in order to get rid of the sampling it needs to
do a ton of passes to get an accurate convergence. What that meant for
me, as an individual, was that animation was out of the question
unless i was willing to work with a grainy image or if i chose to wait
a long time for the frames to be rendered.
Most people these days rely on farms to render with maxwell in an
animation environment (rendernet.se comes to mind).
This was the low side of it, and i hear it is quite similar to arnold
from this standpoint (good quality takes more samples which in turn
takes a longer time to achieve). This is because both engines do not
precompute or cache anything. Brute force is the word here, whereas
vray, even if it does brute force well, it has a ton of other choices
to "cheat" its way through, resulting in a faster rendertime, which in
turn, unfortunately, requires greater knowledge from the user.

On the upside, the shading system was nice, had the usual ubershader
approach, tons of shaders available in the community. Did not use
light sources, but instead turned objects into emitters using a
special shader. That meant the shadows and everything else looked very
realistic. Its preview system was way ahead of anything at that time
in terms of seeing the final look of the image, in the first pass, so
you could get a very good idea if you needed to adjust things before
waiting for 2 hours. Now this has been updated to the maxwell "fire"
engine. But most renderers today give you this (modo's preview or
vray's light cache come to mind). By far the most useful feature of
the engine for me, was its mxi image format (similar to a raw file),
which stored lighting information from all the light sources. That
meant if you had screwed up your exposure, lights etc, you could fix
everything afterwards, and i don't mean brightness/contrast fix. You
could dial the lights in and out, change their intensity, etc, and
everything would update realtime in it's "image editor". I hear now
they have a nuke plugin for this.
Worked for sequences of frames as well, and was a lifesaver.
I remember this one time i had an interior to render for a client, and
it had around 50 lights total.
The guy did a dozen variations, changing colors and turning lights on
and off. Had it not been for this feature,
i would have been rendering a week on the project.
With it, i just waited a couple of hours, and then did a dozen
variations in half an hour from the same render.

Final thing i'd like to point out, was that its xsi integration was
not that good nor stable back then.
Maybe now things have changed, but last i looked, it was pretty much
the same workflow.

Cheers,
O

Re: Softimage 2013/2014 Irradiance Particles - IP Optimize still single threaded?

[Andy Jones]

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: Softimage 2013/2014 Irradiance Particles - IP Optimize still single threaded?

[Steven Caron]

i wouldn't say arnold is as fast at displacement as a reyes
renderer ought to be. also their is the quality to compare too.

i really like arnold, but i hate to see it being built up to be magical
without actual fact to back it up. i would hazard a guess that vray and
arnold displacement are closer than you might think.


On Fri, Mar 29, 2013 at 12:12 PM, Octavian Ureche  wrote:

> Hey Steven,
>
> No i have not directly.
> But having looked at arnold videos on the net, with computer specs given,
> i can state that from what i have seen, arnold is close to mantra in terms
> of displacement speed (which i have used). So it is close to a reyes
> renderer in that sense. Again, this is comparing what i know to what i have
> seen (but you can't really cheat rendering speed).
> Vray is definitely not that fast.
>

Re: Softimage 2013/2014 Irradiance Particles - IP Optimize still single threaded?

[Octavian Ureche]

Hey Steven,

No i have not directly.
But having looked at arnold videos on the net, with computer specs given, i
can state that from what i have seen, arnold is close to mantra in terms of
displacement speed (which i have used). So it is close to a reyes renderer
in that sense. Again, this is comparing what i know to what i have seen
(but you can't really cheat rendering speed).
Vray is definitely not that fast.

RE: Softimage 2014

[Luc-Eric Rousseau]

Modo doesn't have construction history (afaik), what does it do to better
deal with texturing and iterative workflow you mention?
Le 2013-03-28 18:00, "Matt Lind"  a écrit :

> Freeze isn’t ‘deadly’ per se, but it to get around many of the
> instabilities of Softimage we’ve had to resort to using it heavily.
>
> ** **
>
> I don’t think it’s a case of which app mimics the workflow desired, it’s
> more a matter of what problem we’re trying to solve as artists producing
> content for a game development effort.
>
> ** **
>
> What is deceiving is seeing a texture operator buried under a sample
> cluster, but it being affected by operations in the main construction
> history without a visual to inform users there is an existing relationship
> between the two.  Users only look in the sample clusters when needing to
> get information such as the _Def property to animate the projection – which
> is not very often.  When clicking “Freeze” or “Freeze M”, it doesn’t
> register in the user’s mind the texture operator(s) will be affected.  You
> also cannot expect an ordinary user to hover the mouse over the operator to
> get information.  That is more of a TD thing when developing a new tool or
> workflow and would be used in building test cases, prototypes, or
> diagnosing bugs reported by artists.  A niche case.
>
> ** **
>
> The construction history needs a concept of selective freezing as opposed
> to muting or disabling from a given location upwards.  Groups of operators
> need to be able to be merged or rearranged independently, possibly even
> flagged to be immune from freezing so only surrounding operators are
> frozen.  Yes, there are dependencies in some cases such as with deleting
> subcomponents, but a workflow needs to be devised to better inform and work
> with the user’s desires to edit topology.
>
> ** **
>
> The most common reasons for freezing construction history are:
>
> ** **
>
> 1) History gets too large causing performance slowdown and instability.***
> *
>
> ** **
>
> 2) Content is in a finished state and needs to be published for use in
> other scenes by other users.  Example, a prop or tree which serves in a
> larger environment, possibly referenced in multiple locations (eg. Hundreds
> of times).  Any construction history that requires evaluation only bogs
> down the entire scene N fold.
>
> ** **
>
> One problem with the freeze mechanism is it’s not granular enough.  Many a
> time an artist will accumulate hundreds or thousands of operators on the
> construction history while modeling, but can’t afford to freeze the entire
> stack because he many need to retain a specific subset which is providing a
> certain workflow enhancement specific to the asset.  The subset that needs
> to be retained will be buried in the middle of the construction history and
> cannot be isolated without significant work on behalf of the user, or
> cannot be isolated due to technical limitations of Softimage’s
> architecture.  Certainly been a gripe of mine dating back to v1.0.  This is
> exactly the problem with texture operators.  They live in the middle of the
> modeling construction history which forces the user to plan every edit
> ahead of time because as soon as they freeze even once, they’ve lost most
> of their texturing workflow such as the preserve UVs, or ability to unfold,
> or ability to use regularize and other needed features which are accepted
> as standards in other applications and can be applied in any order.  I
> agree texturing should be the last step in the process, but game
> development is a heavily iterative process.  It’s extremely rare for an
> asset to not get kicked back for revisions, usually tens or hundreds of
> times due to art direction or game design modifications.  Sometimes even
> for performance reasons as it may tax the game engine too much by invoking
> too many batches or pull too many textures flooding TRAM.  Therefore it’s
> not possible to do all modeling first, then texturing last.  
>
> ** **
>
> The tools need to recognize that fact first and foremost.  If they don’t,
> then it doesn’t matter what fancy algorithms are used to unfold or do other
> fancy stuff because the amount of roadblocks of the basic workflow will
> outweigh the benefits provided by the fancy tools.  This is exactly the
> reason why our character modeling team uses Modo instead of Softimage for
> their work.  Modo’s tools aren’t all that fancy, but they work together in
> a nice convenient package.  Softimage hasn’t evolved much in this area in
> at least a decade.
>
> ** **
>
> ** **
>
> Matt
>
> ** **
>
> ** **
>
> ** **
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Luc-Eric Rousseau
> *Sent:* Thursday, March 28, 2013 1:49 PM
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: Softimage 2014
>
> ** **
>
> which app works the way you think things should work?
>
> If "Freeze" is 

RE: Softimage 2014

[Matt Lind]

It's not about whether we can freeze a texture projection or not.  The issue is 
about the Softimage API and it's limitations to do things we need to do to be 
really productive.

There are areas which are not developed in line with our needs, and in some 
cases are blocking issues.  Texture operator freezing was just one of them as 
you cannot effectively model and texture at the same time because freezing 
modeling construction history also freezes texture operators, but the 
relationships is not clear to the user.  Once a texture operator is frozen, you 
lose certain abilities such as the 'preserve UVs' workflow.  This effectively 
forces users to complete all modeling before beginning to texture.  This is not 
realistic because in the case of games development the process is heavily 
iterative.  Just because an asset is modeled and textured then sent into the 
game engine does not imply the asset needs no further work.  In fact, it's just 
the opposite as the real work has just begun.

Once an asset gets into a game engine, a whole other level of workflow enters 
the picture from game play, performance balancing, art direction, beta testing, 
market research, and so on.  Assets on average go through at least 15-20 
revisions before deemed 'approved'.  That means an artist performing revisions 
is beginning with an asset that is completed with geometry and texture, but no 
construction history or texture operators present in the scene.  The problem is 
the artist needs to make the same edits to textures as they would as if 
creating the textures from scratch - including preserve UVs, regularize, relax, 
unfold, and other common operations. This is the block as many of the functions 
aren't available once texture operators are frozen.  You have to redo your work 
from scratch to get into an edit friendly position to continue the edit process 
which is prohibitively expensive in time and energy.  The fact a software 
developer who claims to understand our market continues to push out workflows 
like this is rather frustrating.

When project Moondust was first revealed, it was a very exciting moment because 
it hinted at the potential to remove many of the barriers we experience in 
production.  While it certainly gave Softimage instant legitimacy in the area 
of Particle work, it didn't provide the same impact to other areas of the 
software, in many cases only retreading established ground, or not supporting 
as much as established systems.  Modeling comes to mind. While topology 
generators are unique to ICE and not available in the C++ SDK, the rest of the 
ICE modeling system only supports a subset provided by the C++ SDK.  This makes 
it very difficult to make custom tools because our assets are loaded with 
custom properties and metadata which are the main mechanisms to pass 
information from Softimage to our game engine.  ICE doesn't support custom 
properties or metadata or cluster properties in many operations such as merging 
or copying which basically makes them off limits for production as using an ICE 
modeling tool would destroy data we need to maintain.  From our perspective, 
it's as if ICE modeling doesn't exist.  We'd prefer it be an option in our 
pipeline, but to make that a reality, systems need to be completed and barriers 
removed.

It's a design issue.

Matt





From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Simon Reeves
Sent: Friday, March 29, 2013 4:15 AM
To: softimage@listproc.autodesk.com
Subject: Re: Softimage 2014

Diving in a bit here so apologies if I missed it, but you can freeze uv's and 
keep the projection, and unfreeze it at any time. There's a little 'freeze' 
button in one of the texture properties somewhere.
Ill look where it is exactly when I'm infront of soft

Simon Reeves
VFX Artist
London, UK

On 29 Mar 2013, at 06:42, Szabolcs Matefy 
mailto:szabol...@crytek.com>> wrote:
Shit hits the fan, when you want to to have sculpt like deformation in XSI. 
Unfortunately the current system doesn't let you build up your strokes 
properly, due to the weightmap limitation. What I think, that each "stroke" 
should have its own weight map, but that would slaughter the performance. The 
graphite toolset has quite nice things, but our max artist hate it, it's 
nowhere close to the original polyboost feature set.

Maybe, texture should have its own history stack? And an additional Freeze T 
button to freeze texturing only? Anyway, while a texture operator is live, I'd 
sometimes have it sit on the top of the stack, so the Texture History is a good 
idea.

I tried to recreate for example, the DPK Paint Deform 
(http://dpk.stargrav.com/pafiledb/pafiledb.php?action=file&id=32) with ICE, and 
more or less succeeded. Unfortunately the buildup is missing (when your strokes 
are accumulating, causing the increased effect. Maya's artisan treats it pretty 
well. And since I do all of my modeling with my Wacom pen, I'd be happy

Re: Softimage 2013/2014 Irradiance Particles - IP Optimize still single threaded?

[Christopher]

What about Maxwell, which 
render has lots it's potential ?





Christopher


Sent from my Desktop ;-)


 	   
   	Steven Caron  
  Friday, March 29,
 2013 2:19 PM
  you state that 
like its common knowledge... i just wanted to know if you have compared 
arnold's displacement to vray's? i haven't and would like to know.

  
   	   
   	Octavian Ureche  
  Friday, March 29,
 2013 2:06 PM
  Displacement is fast, but 
obviously not as fast as a reyes renderer or arnold. Hair rendering has 
also improved lately, and motionblur and dof are okay. Nowhere near 
arnold but way faster than mental ray. The thing to note about vray is 
that it requires a bit more knowledge about its inner workings to be 
able to get the most of it. But it's an extremely stable and reliable 
renderer. Also on the plus side it handles interiors extremely well, and
 its ibl tools are stellar.

Don't get me wrong, i am not afilliated with chaos group in any way even
 though i was on the beta. It's just my personal view on the engine. I'm
 sure arnold's  algorithms will improve with time, and when it starts 
being less prohibitive , vray will have quite some heavy competition on 
the freelance/small studio front. For that matter Redshift looks 
extremely promising as well. But for the past couple of years, vray gave
 me the piece of mind i never had with mentalray, and i'm thankful to 
the peeps at chaos group for that.

Cheers


  
   	   
   	Christopher  
  Friday, March 29,
 2013 11:03 AM
  

Vray seems to be getting 
so much attention, how does it render displacement mapping, fast ?

Christopher


  
   	   
   	Kamen Lilov  
  Friday, March 29,
 2013 10:59 AM
  To be precise, this is the 
price of one interactive license, which also 
comes with 5 render nodes (you get 10 nodes with VRay for Maya). If you 
render static scenes with DR, you can use all 6 licenses at the same 
time. (we do not recommend rendering animated sequences with DR, except 
for brute force GI)



   	   
   	Octavian Ureche  
  Friday, March 29,
 2013 4:23 AM
  Price wise, last i checked, 
vray was just about under 1k and came with 10 render nodes. But i'm also
 looking forward to an official price for redshift. Might be quite 
tempting if it's in the right ballpark.


  

Re: Softimage 2013/2014 Irradiance Particles - IP Optimize still single threaded?

[Steven Caron]

you state that like its common knowledge... i just wanted to know if you
have compared arnold's displacement to vray's? i haven't and would like to
know.


On Fri, Mar 29, 2013 at 11:06 AM, Octavian Ureche  wrote:

> Displacement is fast, but obviously not as fast as a reyes renderer or
> arnold.
>

Re: Softimage 2013/2014 Irradiance Particles - IP Optimize still single threaded?

[Octavian Ureche]

Displacement is fast, but obviously not as fast as a reyes renderer or
arnold. Hair rendering has also improved lately, and motionblur and dof are
okay. Nowhere near arnold but way faster than mental ray. The thing to note
about vray is that it requires a bit more knowledge about its inner
workings to be able to get the most of it. But it's an extremely stable and
reliable renderer. Also on the plus side it handles interiors extremely
well, and its ibl tools are stellar.
Don't get me wrong, i am not afilliated with chaos group in any way even
though i was on the beta. It's just my personal view on the engine. I'm
sure arnold's  algorithms will improve with time, and when it starts being
less prohibitive , vray will have quite some heavy competition on the
freelance/small studio front. For that matter Redshift looks extremely
promising as well. But for the past couple of years, vray gave me the piece
of mind i never had with mentalray, and i'm thankful to the peeps at chaos
group for that.

Cheers
On Mar 29, 2013 4:04 PM, "Christopher" 
wrote:

> Vray seems to be getting so much attention, how does it render
> displacement mapping, fast ?
>
> Christopher
>
>   Kamen Lilov 
>  Friday, March 29, 2013 10:59 AM
>
> To be precise, this is the price of one interactive license, which also
> comes with 5 render nodes (you get 10 nodes with VRay for Maya). If you
> render static scenes with DR, you can use all 6 licenses at the same time.
> (we do not recommend rendering animated sequences with DR, except for brute
> force GI)
>
>
>   Octavian Ureche 
>  Friday, March 29, 2013 4:23 AM
>
> Price wise, last i checked, vray was just about under 1k and came with 10
> render nodes. But i'm also looking forward to an official price for
> redshift. Might be quite tempting if it's in the right ballpark.
>   Octavian Ureche 
>  Friday, March 29, 2013 4:20 AM
>
> You do know vray is also available for softimage and it's pretty well
> integrated and production proven.
>
> Cheers,
> Octav
>   Christopher 
>  Friday, March 29, 2013 1:19 AM
> How much is it going to cost ? My arm and leg, which are in good condition
> :)
>
> Christopher
>
>
>   Emilio Hernandez 
>  Friday, March 29, 2013 12:38 AM
> A new render engine is coming for Softimage.  Redshift 3d.  I am in the
> alpha test group and all I can say it is an amazing render engine.  It is
> GPU based and it is amazing fast.  It's integration with Softimage is
> seamless.  Easy to setup and you will be rendering without flicker in no
> time.
>
> The results are amazing.  This one is going to ksa.
>
>
>
>
>
> --
>
>
<><><>

RE: Softimage 2014

[Ponthieux, Joseph G. (LARC-E1A)[LITES]]

I think we should just go back to Softimage Particle? :)

--
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 olivier jeannel
Sent: Friday, March 29, 2013 1:02 PM
To: softimage@listproc.autodesk.com
Subject: Re: Softimage 2014

Stop asking things for modeling and texturing ! We're a particle system for God 
Sake !

:D











Le 29/03/2013 12:15, Simon Reeves a écrit :
Diving in a bit here so apologies if I missed it, but you can freeze uv's and 
keep the projection, and unfreeze it at any time. There's a little 'freeze' 
button in one of the texture properties somewhere.
Ill look where it is exactly when I'm infront of soft

Simon Reeves
VFX Artist
London, UK

On 29 Mar 2013, at 06:42, Szabolcs Matefy 
mailto:szabol...@crytek.com>> wrote:
Shit hits the fan, when you want to to have sculpt like deformation in XSI. 
Unfortunately the current system doesn't let you build up your strokes 
properly, due to the weightmap limitation. What I think, that each "stroke" 
should have its own weight map, but that would slaughter the performance. The 
graphite toolset has quite nice things, but our max artist hate it, it's 
nowhere close to the original polyboost feature set.

Maybe, texture should have its own history stack? And an additional Freeze T 
button to freeze texturing only? Anyway, while a texture operator is live, I'd 
sometimes have it sit on the top of the stack, so the Texture History is a good 
idea.

I tried to recreate for example, the DPK Paint Deform 
(http://dpk.stargrav.com/pafiledb/pafiledb.php?action=file&id=32) with ICE, and 
more or less succeeded. Unfortunately the buildup is missing (when your strokes 
are accumulating, causing the increased effect. Maya's artisan treats it pretty 
well. And since I do all of my modeling with my Wacom pen, I'd be happy with a 
proper sculpting tool. And not to mention, the ability to disable the weightmap 
display during sculpting...Seeing the model in constant shading with the weight 
map is not really help in deformation.


My 2 cents

Szabolcs

From: 
softimage-boun...@listproc.autodesk.com
 [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Sebastien 
Sterling
Sent: Friday, March 29, 2013 12:31 AM
To: softimage@listproc.autodesk.com
Subject: Re: Softimage 2014

I agree with matt, if only to add a new tab like m freeze, but which would 
preserve texture,

the tool you are talking about in max is called paint deformation, and it is at 
the bottom of the edit poly operation menu, you can push pull relax, its 
basically like artisan in maya.
On 28 March 2013 23:08, Matt Lind 
mailto:ml...@carbinestudios.com>> wrote:
I think the point is that many of these features are not readily available out 
of the box.  We have to write the tools ourselves and there are many blockades 
to getting the job done.

I have the ICE compound Guillame LaForge sent out last year, but it's a bit hit 
and miss.  We're not supporting ICE in our pipeline yet due to instability when 
using ICE on reference models.  80% of our content is referenced models.  I 
cannot let ICE compounds run amok in scenes that become referenced models and 
are reused in hundreds of other scenes.  We don't have the bandwidth to manage 
such a situation.

Paint - Softimage is light years behind everybody else.  That is the point.  
Their animation-first mindset has been an obstacle to developing a pipeline as 
the parts we need most are modeling and texturing.  Animation is nice, but it 
too lacks a lot of tools and workflows expected out of the box.

Max does have tools to modify topology as our character artist showed me the 
tools a year or so ago spurring me to request the same from Softimage.  They 
had the ability to pinch and pull, displace, as well as cut into the mesh 
almost like Zbrush.  ZBrush was definitely more robust, but what Max offered 
was enough for what we needed to do.  I'm not a Max user, so don't ask me the 
names of the tools.  The best I can remember was something to do with a 
graphite toolset and the brush has the ability to have operators assigned to it 
so they could be painted on meshes.  It was intuitive - something which 
softimage's paint workflow is anything but.

Matt



From: 
softimage-boun...@listproc.autodesk.com
 
[mailto:softimage-boun...@listproc.autodesk.com]
 On Behalf Of Ahmidou Lyazidi
Sent: Wednesday, March 27, 2013 4:32 PM

To: softimage@listproc.autodesk.com
Subject: Re: Soft

Re: Softimage 2014

[olivier jeannel]

Stop asking things for modeling and texturing ! We're a particle system 
for God Sake !


:D











Le 29/03/2013 12:15, Simon Reeves a écrit :
Diving in a bit here so apologies if I missed it, but you can freeze 
uv's and keep the projection, and unfreeze it at any time. There's a 
little 'freeze' button in one of the texture properties somewhere.

Ill look where it is exactly when I'm infront of soft

Simon Reeves
VFX Artist
London, UK

On 29 Mar 2013, at 06:42, Szabolcs Matefy > wrote:


Shit hits the fan, when you want to to have sculpt like deformation 
in XSI. Unfortunately the current system doesn’t let you build up 
your strokes properly, due to the weightmap limitation. What I think, 
that each “stroke” should have its own weight map, but that would 
slaughter the performance. The graphite toolset has quite nice 
things, but our max artist hate it, it’s nowhere close to the 
original polyboost feature set.


Maybe, texture should have its own history stack? And an additional 
Freeze T button to freeze texturing only? Anyway, while a texture 
operator is live, I’d sometimes have it sit on the top of the stack, 
so the Texture History is a good idea.


I tried to recreate for example, the DPK Paint Deform 
(http://dpk.stargrav.com/pafiledb/pafiledb.php?action=file&id=32) 
with ICE, and more or less succeeded. Unfortunately the buildup is 
missing (when your strokes are accumulating, causing the increased 
effect. Maya’s artisan treats it pretty well. And since I do all of 
my modeling with my Wacom pen, I’d be happy with a proper sculpting 
tool. And not to mention, the ability to disable the weightmap 
display during sculpting…Seeing the model in constant shading with 
the weight map is not really help in deformation.


My 2 cents

Szabolcs

*From:*softimage-boun...@listproc.autodesk.com 
 
[mailto:softimage-boun...@listproc.autodesk.com] *On Behalf Of 
*Sebastien Sterling

*Sent:* Friday, March 29, 2013 12:31 AM
*To:* softimage@listproc.autodesk.com 


*Subject:* Re: Softimage 2014

I agree with matt, if only to add a new tab like m freeze, but which 
would preserve texture,


the tool you are talking about in max is called paint deformation, 
and it is at the bottom of the edit poly operation menu, you can push 
pull relax, its basically like artisan in maya.


On 28 March 2013 23:08, Matt Lind > wrote:


I think the point is that many of these features are not readily 
available out of the box.  We have to write the tools ourselves and 
there are many blockades to getting the job done.


I have the ICE compound Guillame LaForge sent out last year, but it’s 
a bit hit and miss.  We’re not supporting ICE in our pipeline yet due 
to instability when using ICE on reference models. 80% of our content 
is referenced models.  I cannot let ICE compounds run amok in scenes 
that become referenced models and are reused in hundreds of other 
scenes.  We don’t have the bandwidth to manage such a situation.


Paint – Softimage is light years behind everybody else. That is the 
point.  Their animation-first mindset has been an obstacle to 
developing a pipeline as the parts we need most are modeling and 
texturing.  Animation is nice, but it too lacks a lot of tools and 
workflows expected out of the box.


Max does have tools to modify topology as our character artist showed 
me the tools a year or so ago spurring me to request the same from 
Softimage.  They had the ability to pinch and pull, displace, as well 
as cut into the mesh almost like Zbrush.  ZBrush was definitely more 
robust, but what Max offered was enough for what we needed to do.  
I’m not a Max user, so don’t ask me the names of the tools.  The best 
I can remember was something to do with a graphite toolset and the 
brush has the ability to have operators assigned to it so they could 
be painted on meshes.  It was intuitive – something which softimage’s 
paint workflow is anything but.



Matt

*From:*softimage-boun...@listproc.autodesk.com 
 
[mailto:softimage-boun...@listproc.autodesk.com 
] *On Behalf Of 
*Ahmidou Lyazidi

*Sent:* Wednesday, March 27, 2013 4:32 PM


*To:* softimage@listproc.autodesk.com 


*Subject:* Re: Softimage 2014

Hi Matt, as you moved to 2013 lately, there might be workarounds for 
some of you problems.


*
Preserve UVs*: I think it's not publicly available, but piotrek did a 
swim UVs for explicit using the custom tool SDK, so it's doable.


*Pain*t: A Maya Artisan like paint tool is also possible, I have an 
unfinished one, it's only doing push and smooth, but working, I also 
never found the time to implement undo/redo.


Also I'm not sure that maya and max have a brush to modify topology.


*Locking topology*: Since 2012 ther

RE: Finalgathering made less frustrating: mx_fgshooter

[Sven Constable]

I did tests with the fgshooter a few weeks ago on the classroom scene. And
yes, its implemention is awful.  I used the fgshooter addon too, its way
easier then.
Btw. I'm also still  on the classroom scene and added light and camera
animation, but I had no time to finish it yet. My goal is to make it as
realistic as possible and bring mentalray onto its knees.:)  Of course it
has to be flickerfree, what is very hard when the sun is animated and it
goes to the horizon resulting in only a few very bright spots in the scene
that has to lit the whole room evenly.

-Original Message-
From: softimage-boun...@listproc.autodesk.com
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Tim Leydecker
Sent: Friday, March 29, 2013 15:36
To: softimage@listproc.autodesk.com
Subject: Finalgathering made less frustrating: mx_fgshooter

Hi guys,


there´s a lot to be desired about mental ray´s implementation and user
friendliness. I don´t even want to start about having at least an in depth
documentation including practical examples.

Nevertheless, there´s yet another node that may come in handy but has
probably slipped your radar:

mip_fgshooter

It is supposed to be used to add finalgather calculations from additional
cameras to your current frame´s fgmap or your *.fgmap in general.

I can´t express how frustrated I am about the implementation in Softimage.

If you ever had hoped to having to figure out how to enter 4x4 matrixes and
get the thing working yourself, brace for a lot of frustration.

Or use this implementation. Thank you Denis Belyatsky!

http://maxfoxlab.com/mx_fgshooter.html

Hats off.

If you push his implementation hard, you´ll notice the camera_shooter_cams
will always have to point to the world origin to give realiable values for
their resulting 4x4 matrixes entered into the render cam´s mip_fgshooter
item list.

Sofar, I haven´t been able to verify if that is a limitation of using their
[cameraname].kineGlobal as the source for the 4x4 matrix or if that is due
to the way the mip_fgshooter node interprets coordinates?

In any case, Denis plugin is a great helper in actually making flickerfree
FG available to the average user who may sure not be able to derive and
properly set a 4x4 matrix himself.

In terms of useability, I would have expected mip_fg_shooter to have a list
entry field where you pick your cameras and that´s it. Like Lightlinking for
selective light, even SRT coordinates would have been better but transform
matrixes, really?

That´s defeating the whole point of keeping it simple unless one could drag
and drop a camera into the Rendertree and at least connect it directly
there. Which you can´t...

Cheers,

tim

Re: Softimage 2013/2014 Irradiance Particles - IP Optimize still single threaded?

[Christopher]

Vray seems to be getting 
so much attention, how does it render displacement mapping, fast ?

Christopher


   	   
   	Kamen Lilov  
  Friday, March 29,
 2013 10:59 AM
  To be precise, this is the 
price of one interactive license, which also 
comes with 5 render nodes (you get 10 nodes with VRay for Maya). If you 
render static scenes with DR, you can use all 6 licenses at the same 
time. (we do not recommend rendering animated sequences with DR, except 
for brute force GI)



   	   
   	Octavian Ureche  
  Friday, March 29,
 2013 4:23 AM
  Price wise, last i checked, 
vray was just about under 1k and came with 10 render nodes. But i'm also
 looking forward to an official price for redshift. Might be quite 
tempting if it's in the right ballpark.


  
   	   
   	Octavian Ureche  
  Friday, March 29,
 2013 4:20 AM
  You do know vray is also 
available for softimage and it's pretty well integrated and production 
proven. 
Cheers, 
Octav


  
   	   
   	Christopher  
  Friday, March 29,
 2013 1:19 AM
  How much is it going to cost ? 
My arm and leg, which are in good 
condition :)

Christopher


   	   
   	Emilio Hernandez  
  Friday, March 29,
 2013 12:38 AM
  A new render 
engine is coming for Softimage.  Redshift 3d.  I am in the alpha test 
group and all I can say it is an amazing render engine.  It is GPU based
 and it is amazing fast.  It's integration with Softimage is seamless. 
 Easy to setup and you will be rendering without flicker in no time.
The results are amazing.  This one is going to 
ksa.--
 


  

Re: Softimage 2013/2014 Irradiance Particles - IP Optimize still single threaded?

[Kamen Lilov]

On 3/29/2013 10:23 AM, Octavian Ureche wrote:


Price wise, last i checked, vray was just about under 1k and came with 
10 render nodes. But i'm also looking forward to an official price for 
redshift. Might be quite tempting if it's in the right ballpark.


To be precise, this is the price of one interactive license, which also 
comes with 5 render nodes (you get 10 nodes with VRay for Maya). If you 
render static scenes with DR, you can use all 6 licenses at the same 
time. (we do not recommend rendering animated sequences with DR, except 
for brute force GI)

Finalgathering made less frustrating: mx_fgshooter

[Tim Leydecker]

Hi guys,


there´s a lot to be desired about mental ray´s implementation
and user friendliness. I don´t even want to start about having
at least an in depth documentation including practical examples.

Nevertheless, there´s yet another node that may come in handy but
has probably slipped your radar:

mip_fgshooter

It is supposed to be used to add finalgather calculations from
additional cameras to your current frame´s fgmap or your *.fgmap
in general.

I can´t express how frustrated I am about the implementation in Softimage.

If you ever had hoped to having to figure out how to enter 4x4 matrixes
and get the thing working yourself, brace for a lot of frustration.

Or use this implementation. Thank you Denis Belyatsky!

http://maxfoxlab.com/mx_fgshooter.html

Hats off.

If you push his implementation hard, you´ll notice the camera_shooter_cams
will always have to point to the world origin to give realiable values for
their resulting 4x4 matrixes entered into the render cam´s mip_fgshooter item 
list.

Sofar, I haven´t been able to verify if that is a limitation of using their
[cameraname].kineGlobal as the source for the 4x4 matrix or if that is due
to the way the mip_fgshooter node interprets coordinates?

In any case, Denis plugin is a great helper in actually making flickerfree FG
available to the average user who may sure not be able to derive and properly 
set
a 4x4 matrix himself.

In terms of useability, I would have expected mip_fg_shooter to have a list 
entry field
where you pick your cameras and that´s it. Like Lightlinking for selective 
light,
even SRT coordinates would have been better but transform matrixes, really?

That´s defeating the whole point of keeping it simple unless one could drag and 
drop
a camera into the Rendertree and at least connect it directly there. Which you 
can´t...

Cheers,

tim

Friday Flashback #113

[Stephen Blair]

Friday Flashback #113
2008 VCC Blaupunkt ICE demo
http://wp.me/powV4-2Ep

Re: Kojima san uses Softimage in MGS 5! Again!

[Tim Leydecker]

Personally,

I really like the detail in the BF3 characters&assets&environment.

If you google a bit you can find a few of the characters in 3ds/maya/xsi format,
including textures sometimes, there´s loads of people using these meshes for
their own mods or as proportions&detail reference for their own (realtime) 
meshes.

In terms of weapons and recognizeable gear detail, the BF stuff is really sweet.

All the latest and greatest custom options for your SAW or M4 you could want...

The MGS5 stuff on the other hand has obviously more focus on telling a story in
a different scenario, e.g. it has more options to deviate from the battlefield 
setting.

But in general both games have kick arse art direction and attention to detail 
imo.

What´s really sweet in the MGS5 presentation is how detailed they show their 
engine
and how they go about creating believable detail especially in textures, 
lighting and shading.

A lot of that stuff translates really nice to offline rendering, too.
One nice bit for example is the angle-dependent glossiness of surfaces in 
shading, just great.

Or the wetness effect they get my globally pushing glossiness on demand.

When I first saw the first few examples in the MGS5 engine, I thought it looked 
boring
until I realized that was because the engine first of all creates real-world 
lighting
with proper gamma, which means images may initially look less 
saturated&contrasty than
your average game/hip-hop video look but it´s easy enough to get that look if 
you want.

The BF engine is also really nice, thought.

In conlcusion, I am deeply impressed from both.


Cheers,

tim





On 29.03.2013 13:42, Juhani Karlsson wrote:

I have to say that while BF4 might have pretty pixels it does looks very
pale compared to MGS in art direction.
There is level of symbolism and depth in it that BF completely lacks.
Different games naturally - just my opinion.

- J

On 28 March 2013 16:02, Marc-Andre Carbonneau <
marc-andre.carbonn...@ubisoft.com> wrote:


Nice but I think this is better looking.

** **


www.gametrailers.com/videos/2z61g8/battlefield-4-fishing-in-baku-gameplay-demo


** **

** **

*From:* softimage-boun...@listproc.autodesk.com [mailto:
softimage-boun...@listproc.autodesk.com] *On Behalf Of *olivier jeannel
*Sent:* 28 mars 2013 09:58
*To:* softimage@listproc.autodesk.com
*Subject:* Re: Kojima san uses Softimage in MGS 5! Again!

** **

Japaneses, when they do things, they don't do half...
Excellent video, thanks for showing it !

Le 28/03/2013 13:56, Szabolcs Matefy a écrit :


http://www.youtube.com/watch?feature=player_detailpage&v=FQMbxzTUuSg#t=1880s


  

But worth a look the whole thing…amazing J

___
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: Kojima san uses Softimage in MGS 5! Again!

[Juhani Karlsson]

I have to say that while BF4 might have pretty pixels it does looks very
pale compared to MGS in art direction.
There is level of symbolism and depth in it that BF completely lacks.
Different games naturally - just my opinion.

- J

On 28 March 2013 16:02, Marc-Andre Carbonneau <
marc-andre.carbonn...@ubisoft.com> wrote:

> Nice but I think this is better looking.
>
> ** **
>
>
> www.gametrailers.com/videos/2z61g8/battlefield-4-fishing-in-baku-gameplay-demo
> 
>
> ** **
>
> ** **
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *olivier jeannel
> *Sent:* 28 mars 2013 09:58
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: Kojima san uses Softimage in MGS 5! Again!
>
> ** **
>
> Japaneses, when they do things, they don't do half...
> Excellent video, thanks for showing it !
>
> Le 28/03/2013 13:56, Szabolcs Matefy a écrit :
>
>
> http://www.youtube.com/watch?feature=player_detailpage&v=FQMbxzTUuSg#t=1880s
> 
>
>  
>
> But worth a look the whole thing…amazing J
>
> ___
> 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
>
> ** **
>



-- 
-- 
Juhani Karlsson
3D Artist/TD

Talvi Digital Oy
Pursimiehenkatu 29-31 b 2krs.
00150 Helsinki
+358 443443088
juhani.karls...@talvi.fi
www.vimeo.com/talvi

Re: ICE Topo Clone from group of objects onto Particles?

[Dan Yargici]

I can see them (Gmail)

DAN


On Fri, Mar 29, 2013 at 1:32 PM, Stephen Blair wrote:

> Hi Gray
> I don't see any attachments.
> This happened last time you posted a screenshot too. I couldn't find the
> attachments
>
>
>
> On 28/03/2013 6:46 PM, Grahame Fuller wrote:
>
>> Do these compounds help? I've posted before but for some reason the
>> attachments don't seem to make it into the archives.
>>
>> They were designed to copy particle instances to real topology, but
>> obviously you don't actually need instances but just an integer for the
>> object index in the group.
>>
>> Usage notes:
>>
>> To use, put Convert Instances to Mesh in an ICE tree on an empty mesh. It
>> works only with the "self" object. You also need to store the shape index
>> on the point cloud and reference it in the compound's ppg. To transfer
>> attributes, attach one of the Transfer compounds to the Execute port -
>> there's one for each component type.
>>
>> If you transfer the MaterialIDs, then you can use the Copy Materials
>> checkbox. This works only if all objects in the group have identical
>> Materials arrays.
>>
>> The transfer is based on finding locations on the group geometry, so it's
>> best to move the instance masters apart if they overlap.
>>
>> It uses the 2013 version of Build Array from Set which supports
>> topology-type attributes. To use it with Softimage v2012, you'll need to
>> replace it with Build Array from Per Point Data.
>>
>> gray
>>
>> From: 
>> softimage-bounces@listproc.**autodesk.com[mailto:
>> softimage-bounces@**listproc.autodesk.com]
>> On Behalf Of Eric Thivierge
>> Sent: Thursday, March 28, 2013 06:30 PM
>> To: softimage@listproc.autodesk.**com 
>> Subject: Re: ICE Topo Clone from group of objects onto Particles?
>>
>>
>> Thanks but I need it as actual geometry using ice topology
>> On Mar 28, 2013 6:09 PM, "Daryl Dunlap" > mailto:twinsnakes...@gmail.com**>> wrote:
>> Hey Eric,
>>
>> There's an example in the Docs for just that scenario.
>>
>> http://download.autodesk.com/**global/docs/softimage2013/en_**
>> us/userguide/index.html?url=**files/ipart_instances_**
>> UsingGroupsofMasterObjects.**htm,topicNumber=d30e291285
>>
>> On Thu, Mar 28, 2013 at 6:03 PM, Eric Thivierge > > wrote:
>> Trying to clone a group of meshes and place them at particle positions
>> from a cloud using ICE Topo. Is there a way to get any of the built in
>> compounds to do this? Not seeing any compounds or sample scenes doing this.
>>
>> So to review I have 5 meshes in a group and a particle cloud. I want to
>> randomly get a mesh out of the group and stick it where a particle is.
>>
>> --**--
>> Eric Thivierge
>> http://www.ethivierge.com
>>
>>
>

Re: ICE Topo Clone from group of objects onto Particles?

[Stephen Blair]

Hi Gray
I don't see any attachments.
This happened last time you posted a screenshot too. I couldn't find the 
attachments



On 28/03/2013 6:46 PM, Grahame Fuller wrote:

Do these compounds help? I've posted before but for some reason the attachments 
don't seem to make it into the archives.

They were designed to copy particle instances to real topology, but obviously 
you don't actually need instances but just an integer for the object index in 
the group.

Usage notes:

To use, put Convert Instances to Mesh in an ICE tree on an empty mesh. It works only with 
the "self" object. You also need to store the shape index on the point cloud 
and reference it in the compound's ppg. To transfer attributes, attach one of the 
Transfer compounds to the Execute port - there's one for each component type.

If you transfer the MaterialIDs, then you can use the Copy Materials checkbox. 
This works only if all objects in the group have identical Materials arrays.

The transfer is based on finding locations on the group geometry, so it's best 
to move the instance masters apart if they overlap.

It uses the 2013 version of Build Array from Set which supports topology-type 
attributes. To use it with Softimage v2012, you'll need to replace it with 
Build Array from Per Point Data.

gray

From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Eric Thivierge
Sent: Thursday, March 28, 2013 06:30 PM
To: softimage@listproc.autodesk.com
Subject: Re: ICE Topo Clone from group of objects onto Particles?


Thanks but I need it as actual geometry using ice topology
On Mar 28, 2013 6:09 PM, "Daryl Dunlap" 
mailto:twinsnakes...@gmail.com>> wrote:
Hey Eric,

There's an example in the Docs for just that scenario.

http://download.autodesk.com/global/docs/softimage2013/en_us/userguide/index.html?url=files/ipart_instances_UsingGroupsofMasterObjects.htm,topicNumber=d30e291285

On Thu, Mar 28, 2013 at 6:03 PM, Eric Thivierge 
mailto:ethivie...@gmail.com>> wrote:
Trying to clone a group of meshes and place them at particle positions from a 
cloud using ICE Topo. Is there a way to get any of the built in compounds to do 
this? Not seeing any compounds or sample scenes doing this.

So to review I have 5 meshes in a group and a particle cloud. I want to 
randomly get a mesh out of the group and stick it where a particle is.


Eric Thivierge
http://www.ethivierge.com

Re: Softimage 2014

[Simon Reeves]

Diving in a bit here so apologies if I missed it, but you can freeze uv's
and keep the projection, and unfreeze it at any time. There's a little
'freeze' button in one of the texture properties somewhere.
Ill look where it is exactly when I'm infront of soft

Simon Reeves
VFX Artist
London, UK

On 29 Mar 2013, at 06:42, Szabolcs Matefy  wrote:

Shit hits the fan, when you want to to have sculpt like deformation in XSI.
Unfortunately the current system doesn’t let you build up your strokes
properly, due to the weightmap limitation. What I think, that each “stroke”
should have its own weight map, but that would slaughter the performance.
The graphite toolset has quite nice things, but our max artist hate it,
it’s nowhere close to the original polyboost feature set.



Maybe, texture should have its own history stack? And an additional Freeze
T button to freeze texturing only? Anyway, while a texture operator is
live, I’d sometimes have it sit on the top of the stack, so the Texture
History is a good idea.



I tried to recreate for example, the DPK Paint Deform (
http://dpk.stargrav.com/pafiledb/pafiledb.php?action=file&id=32) with ICE,
and more or less succeeded. Unfortunately the buildup is missing (when your
strokes are accumulating, causing the increased effect. Maya’s artisan
treats it pretty well. And since I do all of my modeling with my Wacom pen,
I’d be happy with a proper sculpting tool. And not to mention, the ability
to disable the weightmap display during sculpting…Seeing the model in
constant shading with the weight map is not really help in deformation.





My 2 cents



Szabolcs



*From:* softimage-boun...@listproc.autodesk.com [
mailto:softimage-boun...@listproc.autodesk.com]
*On Behalf Of *Sebastien Sterling
*Sent:* Friday, March 29, 2013 12:31 AM
*To:* softimage@listproc.autodesk.com
*Subject:* Re: Softimage 2014



I agree with matt, if only to add a new tab like m freeze, but which would
preserve texture,

the tool you are talking about in max is called paint deformation, and it
is at the bottom of the edit poly operation menu, you can push pull relax,
its basically like artisan in maya.

On 28 March 2013 23:08, Matt Lind  wrote:

I think the point is that many of these features are not readily available
out of the box.  We have to write the tools ourselves and there are many
blockades to getting the job done.



I have the ICE compound Guillame LaForge sent out last year, but it’s a bit
hit and miss.  We’re not supporting ICE in our pipeline yet due to
instability when using ICE on reference models.  80% of our content is
referenced models.  I cannot let ICE compounds run amok in scenes that
become referenced models and are reused in hundreds of other scenes.  We
don’t have the bandwidth to manage such a situation.



Paint – Softimage is light years behind everybody else.  That is the
point.  Their animation-first mindset has been an obstacle to developing a
pipeline as the parts we need most are modeling and texturing.  Animation
is nice, but it too lacks a lot of tools and workflows expected out of the
box.



Max does have tools to modify topology as our character artist showed me
the tools a year or so ago spurring me to request the same from Softimage.
They had the ability to pinch and pull, displace, as well as cut into the
mesh almost like Zbrush.  ZBrush was definitely more robust, but what Max
offered was enough for what we needed to do.  I’m not a Max user, so don’t
ask me the names of the tools.  The best I can remember was something to do
with a graphite toolset and the brush has the ability to have operators
assigned to it so they could be painted on meshes.  It was intuitive –
something which softimage’s paint workflow is anything but.


Matt







*From:* softimage-boun...@listproc.autodesk.com [mailto:
softimage-boun...@listproc.autodesk.com] *On Behalf Of *Ahmidou Lyazidi
*Sent:* Wednesday, March 27, 2013 4:32 PM


*To:* softimage@listproc.autodesk.com
*Subject:* Re: Softimage 2014



Hi Matt, as you moved to 2013 lately, there might be workarounds for some
of you problems.

*
Preserve UVs*: I think it's not publicly available, but piotrek did a swim
UVs for explicit using the custom tool SDK, so it's doable.

*Pain*t: A Maya Artisan like paint tool is also possible, I have an
unfinished one, it's only doing push and smooth, but working, I also never
found the time to implement undo/redo.

Also I'm not sure that maya and max have a brush to modify topology.


*Locking topology*: Since 2012 there is a pin UVs that survive to freeze.
I'm surprise that a all levels locked ICE tree can be freezed (bug?!), but
you ca still make an operator that will lock a point and all it's attached
properties.

Locked operators are not freezable.



Cheers

---
Ahmidou Lyazidi
Director | TD | CG artist
http://vimeo.com/ahmidou/videos

softimage@listproc.autodesk.com

[Ilija Brunck]

Hello guys,


we are really happy the Halo work is liked here. Thanks a lot!

Here's another piece we just finished:
http://www.polynoid.tv/mtv-idol/

Pit is constantly thinking about writing on monophyl again. :) We all really
hope we find time for it soon.


Who will be at FMX this year? There'll be a Polynoid Party on Tuesday. Would
be great to meet some of you there!

For those who are interested in more details about Halo: We'll talk about
it and other recent productions on Thursday Morning.
http://www.fmx.de/program.html#!/event/1219


Cheers and all the best from Berlin,
Ilija


On Tue, Mar 26, 2013 at 12:26 PM, adrian wyer <
adrian.w...@fluid-pictures.com> wrote:

> ** ** ** ** **
>
> positive press for Softimage, get to it Autodesk...hmmm
>
> ** **
>
> http://motionographer.com/2013/03/25/halo-4-fud-title-sequence-polynoid/**
> **
>
> ** **
>
> a
>
> ** **
>
> Adrian Wyer
> Fluid Pictures
> 75-77 Margaret St.
> London
> W1W 8SY
> ++44(0) 207 580 0829 
>
>
> adrian.w...@fluid-pictures.com
>
> www.fluid-pictures.com 
>
> ** **
>
> Fluid Pictures Limited is registered in **England** and **
> **Wales.
> Company number:5657815
> VAT number: 872 6893 71
>
> ** **
>



-- 
Ilija Brunck

+573183232393
+491773402874
il...@polynoid.tv
www.polynoid.tv

Re: Camera distance to an object

[Emilio Hernandez]

Yes it's working with the null centered.  But what if I want the focus on
some moving object that is not always in the center of the camera and
coming near?  It is like a follow focus rig.




2013/3/29 Ben Davis 

> Makes sense, thanks Tim!
>
> That means that the info from the "Distance to Output Camera" is doing
> exactly what you need Emilio, since when centered the ICETree info matches
> perfectly.
>
> --
> Ben Davis
>
> www.moondog-animation.com
>
> +33 6 88 48 54 50
>
>
> On Fri, Mar 29, 2013 at 10:31 AM, Tim Leydecker  wrote:
>
>> Hey Ben,
>>
>> the farther offset the null is off center to the center of the camera view
>> the more "off" the DOF would be because the DOF effect is sets in respect
>> to the viewplane of the camera and it would take some Pythagorean theorem
>> (http://en.wikipedia.org/wiki/**Hypotenuse)
>> to get the desired major cathetus,
>> which is the Distance between Camera Center and a "Plane" from the shorter
>> cathetus.
>>
>> To avoid that, it愀 easier to constraint the camera to "look at" the null,
>> then the hypothenuse "snaps back into" the longer cathetus and there is
>> no offset anymore to worry about.
>>
>> Cheers,
>>
>> tim
>>
>>
>> On 29.03.2013 10:06, Ben Davis wrote:
>>
>>> It looks like "Distance to Output Camera" from the viewport options is
>>> spitting out the info from a plane in front of the camera based on the
>>> distance from the null if it were in the center of your camera's view. If
>>> your null is centered, the values are the same from the ICETree and the
>>> viewport info.
>>>
>>> The ICE info from the "Get Distance Between" is exactly the distance from
>>> center to center (global.kine to global.kine). I don't see a problem with
>>> using the info from ICE to feed into your DOF, you're probably going to
>>> get
>>> a more precise focus placement (I'll accept being refuted by the
>>> photographers out there :)
>>>
>>> Hope that helps!
>>>
>>> Ben
>>>
>>> --
>>> Ben Davis
>>>
>>> www.moondog-animation.com
>>>
>>> +33 6 88 48 54 50
>>>
>>>
>>> On Fri, Mar 29, 2013 at 9:20 AM, Emilio Hernandez 
>>> wrote:
>>>
>>>  Hello I am trying to rig the camera DOF so I can attach the distance to
 a
 null.  I am the ICE distance between node.  But when I turn on the
 distance
 to output camera from the viewer, it gives me a different result.

 So the Distance to output camera from the viewport options is different
 than the Distance between node in the ICE tree using the kine.global.pos
 from the camera and the null.

 I will appreciate any help on this issue.

 --



>>>
>


--

Re: Softimage 2014

[Dan Yargici]

For brush-based sculpting, Blender also has great tools if anyone's looking
for inspiration.

DAN


On Fri, Mar 29, 2013 at 10:17 AM, Sebastien Sterling <
sebastien.sterl...@gmail.com> wrote:

> That would be Splendid Ahmidou !!! i would owe you a debt in the afterlife
> !
>
>
> On 29 March 2013 08:40, Ahmidou Lyazidi  wrote:
>
>> That's why I talked about workarounds, and I'm not talking about ICE here.
>>
>> When I started my brush I was a C++ newbie, but now I'm sure it's just a
>> matter of a few days, it's really not that complicated, I'll try to
>> finish/improve it a soon as my contract is finished and release it for free.
>>
>> anyway, I only found this about max brush, I can't find any tolopology
>> brush modifier:
>>
>> http://docs.autodesk.com/3DSMAX/15/ENU/3ds-Max-Help/index.html?url=files/GUID-CA6D812A-C92B-4037-8810-E0257C6B61AE.htm,topicNumber=d30e127452
>>
>> and this:
>>
>> http://docs.autodesk.com/3DSMAX/15/ENU/3ds-Max-Help/files/GUID-C87493C2-6E85-4DCB-A0AC-F355A9AA174F.htm
>> that can be replaced by this in SI: https://vimeo.com/41703655#at=0
>>
>> you can as Piotrek for his swim uvs:
>> https://vimeo.com/46540432
>>
>>
>> Cheers
>> ---
>> Ahmidou Lyazidi
>> Director | TD | CG artist
>> http://vimeo.com/ahmidou/videos
>>
>>
>> 2013/3/29 Matt Lind 
>>
>>> I think the point is that many of these features are not readily
>>> available out of the box.  We have to write the tools ourselves and there
>>> are many blockades to getting the job done.
>>>
>>> ** **
>>>
>>> I have the ICE compound Guillame LaForge sent out last year, but it’s a
>>> bit hit and miss.  We’re not supporting ICE in our pipeline yet due to
>>> instability when using ICE on reference models.  80% of our content is
>>> referenced models.  I cannot let ICE compounds run amok in scenes that
>>> become referenced models and are reused in hundreds of other scenes.  We
>>> don’t have the bandwidth to manage such a situation.
>>>
>>> ** **
>>>
>>> Paint – Softimage is light years behind everybody else.  That is the
>>> point.  Their animation-first mindset has been an obstacle to developing a
>>> pipeline as the parts we need most are modeling and texturing.  Animation
>>> is nice, but it too lacks a lot of tools and workflows expected out of the
>>> box.
>>>
>>> ** **
>>>
>>> Max does have tools to modify topology as our character artist showed me
>>> the tools a year or so ago spurring me to request the same from Softimage.
>>> They had the ability to pinch and pull, displace, as well as cut into the
>>> mesh almost like Zbrush.  ZBrush was definitely more robust, but what Max
>>> offered was enough for what we needed to do.  I’m not a Max user, so don’t
>>> ask me the names of the tools.  The best I can remember was something to do
>>> with a graphite toolset and the brush has the ability to have operators
>>> assigned to it so they could be painted on meshes.  It was intuitive –
>>> something which softimage’s paint workflow is anything but.
>>>
>>>
>>> Matt
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> *From:* softimage-boun...@listproc.autodesk.com [mailto:
>>> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Ahmidou Lyazidi
>>> *Sent:* Wednesday, March 27, 2013 4:32 PM
>>>
>>> *To:* softimage@listproc.autodesk.com
>>> *Subject:* Re: Softimage 2014
>>>
>>> ** **
>>>
>>> Hi Matt, as you moved to 2013 lately, there might be workarounds for
>>> some of you problems.
>>>
>>> *
>>> Preserve UVs*: I think it's not publicly available, but piotrek did a
>>> swim UVs for explicit using the custom tool SDK, so it's doable.
>>>
>>> *Pain*t: A Maya Artisan like paint tool is also possible, I have an
>>> unfinished one, it's only doing push and smooth, but working, I also never
>>> found the time to implement undo/redo.
>>>
>>> Also I'm not sure that maya and max have a brush to modify topology.
>>>
>>>
>>> *Locking topology*: Since 2012 there is a pin UVs that survive to
>>> freeze.
>>> I'm surprise that a all levels locked ICE tree can be freezed (bug?!),
>>> but you ca still make an operator that will lock a point and all it's
>>> attached properties.
>>>
>>> Locked operators are not freezable.
>>>
>>> ** **
>>>
>>> Cheers
>>>
>>> ---
>>> Ahmidou Lyazidi
>>> Director | TD | CG artist
>>> http://vimeo.com/ahmidou/videos
>>>
>>
>>
>

Re: Camera distance to an object

[Ben Davis]

Makes sense, thanks Tim!

That means that the info from the "Distance to Output Camera" is doing
exactly what you need Emilio, since when centered the ICETree info matches
perfectly.

--
Ben Davis

www.moondog-animation.com

+33 6 88 48 54 50


On Fri, Mar 29, 2013 at 10:31 AM, Tim Leydecker  wrote:

> Hey Ben,
>
> the farther offset the null is off center to the center of the camera view
> the more "off" the DOF would be because the DOF effect is sets in respect
> to the viewplane of the camera and it would take some Pythagorean theorem
> (http://en.wikipedia.org/wiki/**Hypotenuse)
> to get the desired major cathetus,
> which is the Distance between Camera Center and a "Plane" from the shorter
> cathetus.
>
> To avoid that, it愀 easier to constraint the camera to "look at" the null,
> then the hypothenuse "snaps back into" the longer cathetus and there is
> no offset anymore to worry about.
>
> Cheers,
>
> tim
>
>
> On 29.03.2013 10:06, Ben Davis wrote:
>
>> It looks like "Distance to Output Camera" from the viewport options is
>> spitting out the info from a plane in front of the camera based on the
>> distance from the null if it were in the center of your camera's view. If
>> your null is centered, the values are the same from the ICETree and the
>> viewport info.
>>
>> The ICE info from the "Get Distance Between" is exactly the distance from
>> center to center (global.kine to global.kine). I don't see a problem with
>> using the info from ICE to feed into your DOF, you're probably going to
>> get
>> a more precise focus placement (I'll accept being refuted by the
>> photographers out there :)
>>
>> Hope that helps!
>>
>> Ben
>>
>> --
>> Ben Davis
>>
>> www.moondog-animation.com
>>
>> +33 6 88 48 54 50
>>
>>
>> On Fri, Mar 29, 2013 at 9:20 AM, Emilio Hernandez 
>> wrote:
>>
>>  Hello I am trying to rig the camera DOF so I can attach the distance to a
>>> null.  I am the ICE distance between node.  But when I turn on the
>>> distance
>>> to output camera from the viewer, it gives me a different result.
>>>
>>> So the Distance to output camera from the viewport options is different
>>> than the Distance between node in the ICE tree using the kine.global.pos
>>> from the camera and the null.
>>>
>>> I will appreciate any help on this issue.
>>>
>>> --
>>>
>>>
>>>
>>
<>

Re: Camera distance to an object

[Tim Leydecker]

Hey Ben,

the farther offset the null is off center to the center of the camera view
the more "off" the DOF would be because the DOF effect is sets in respect
to the viewplane of the camera and it would take some Pythagorean theorem
(http://en.wikipedia.org/wiki/Hypotenuse) to get the desired major cathetus,
which is the Distance between Camera Center and a "Plane" from the shorter
cathetus.

To avoid that, it´s easier to constraint the camera to "look at" the null,
then the hypothenuse "snaps back into" the longer cathetus and there is
no offset anymore to worry about.

Cheers,

tim

On 29.03.2013 10:06, Ben Davis wrote:

It looks like "Distance to Output Camera" from the viewport options is
spitting out the info from a plane in front of the camera based on the
distance from the null if it were in the center of your camera's view. If
your null is centered, the values are the same from the ICETree and the
viewport info.

The ICE info from the "Get Distance Between" is exactly the distance from
center to center (global.kine to global.kine). I don't see a problem with
using the info from ICE to feed into your DOF, you're probably going to get
a more precise focus placement (I'll accept being refuted by the
photographers out there :)

Hope that helps!

Ben

--
Ben Davis

www.moondog-animation.com

+33 6 88 48 54 50


On Fri, Mar 29, 2013 at 9:20 AM, Emilio Hernandez  wrote:


Hello I am trying to rig the camera DOF so I can attach the distance to a
null.  I am the ICE distance between node.  But when I turn on the distance
to output camera from the viewer, it gives me a different result.

So the Distance to output camera from the viewport options is different
than the Distance between node in the ICE tree using the kine.global.pos
from the camera and the null.

I will appreciate any help on this issue.

--

Re: Camera distance to an object

[Emilio Hernandez]

Thx Ben.

The thing is the distance between node output is almost twice the distance
reported by the viewport. If I use the value of the Distance Between node,
the focus is farther than the expected.  I am right now dividing the result
by 2 and I think I am getting there and getting the focus plane where I
want.

I am trying to figure out the logic on this and the only thing that comes
up to my mind is that maybe the focus distance is splitted in two.  One
half is from camera to object and the other is from object to camera.
Don't know if I explained myself or is there some logic into this.


2013/3/29 Ben Davis 

> It looks like "Distance to Output Camera" from the viewport options is
> spitting out the info from a plane in front of the camera based on the
> distance from the null if it were in the center of your camera's view. If
> your null is centered, the values are the same from the ICETree and the
> viewport info.
>
> The ICE info from the "Get Distance Between" is exactly the distance from
> center to center (global.kine to global.kine). I don't see a problem with
> using the info from ICE to feed into your DOF, you're probably going to get
> a more precise focus placement (I'll accept being refuted by the
> photographers out there :)
>
> Hope that helps!
>
> Ben
>
> --
> Ben Davis
>
> www.moondog-animation.com
>
> +33 6 88 48 54 50
>
>
> On Fri, Mar 29, 2013 at 9:20 AM, Emilio Hernandez wrote:
>
>> Hello I am trying to rig the camera DOF so I can attach the distance to a
>> null.  I am the ICE distance between node.  But when I turn on the distance
>> to output camera from the viewer, it gives me a different result.
>>
>> So the Distance to output camera from the viewport options is different
>> than the Distance between node in the ICE tree using the kine.global.pos
>> from the camera and the null.
>>
>> I will appreciate any help on this issue.
>>
>> --
>>
>>
>


--

Re: Camera distance to an object

[Ben Davis]

It looks like "Distance to Output Camera" from the viewport options is
spitting out the info from a plane in front of the camera based on the
distance from the null if it were in the center of your camera's view. If
your null is centered, the values are the same from the ICETree and the
viewport info.

The ICE info from the "Get Distance Between" is exactly the distance from
center to center (global.kine to global.kine). I don't see a problem with
using the info from ICE to feed into your DOF, you're probably going to get
a more precise focus placement (I'll accept being refuted by the
photographers out there :)

Hope that helps!

Ben

--
Ben Davis

www.moondog-animation.com

+33 6 88 48 54 50


On Fri, Mar 29, 2013 at 9:20 AM, Emilio Hernandez  wrote:

> Hello I am trying to rig the camera DOF so I can attach the distance to a
> null.  I am the ICE distance between node.  But when I turn on the distance
> to output camera from the viewer, it gives me a different result.
>
> So the Distance to output camera from the viewport options is different
> than the Distance between node in the ICE tree using the kine.global.pos
> from the camera and the null.
>
> I will appreciate any help on this issue.
>
> --
>
>

Re: [Inspiration] Tron Legacy's screens. Motion graphics at its best

[olivier jeannel]

Very interesting Makings of Tron motion graphics, designs and researches 
here :

https://vimeo.com/mn8er/videos/page:1/sort:date



Le 06/04/2011 22:53, Marc-Andre Carbonneau a écrit :


Motion graphics at its best

http://jtnimoy.net/workviewer.php?q=178

Funny guy too. J

MAC

Re: Softimage 2013/2014 Irradiance Particles - IP Optimize still single threaded?

[Octavian Ureche]

Price wise, last i checked, vray was just about under 1k and came with 10
render nodes. But i'm also looking forward to an official price for
redshift. Might be quite tempting if it's in the right ballpark.
On Mar 29, 2013 9:20 AM, "Octavian Ureche"  wrote:

> You do know vray is also available for softimage and it's pretty well
> integrated and production proven.
>
> Cheers,
> Octav
> On Mar 29, 2013 6:20 AM, "Christopher" 
> wrote:
>
>> How much is it going to cost ? My arm and leg, which are in good
>> condition :)
>>
>> Christopher
>>
>> Emilio Hernandez wrote:
>>
>>> Redshift 3d
>>>
>>

Re: Softimage 2013/2014 Irradiance Particles - IP Optimize still single threaded?

[Octavian Ureche]

You do know vray is also available for softimage and it's pretty well
integrated and production proven.

Cheers,
Octav
On Mar 29, 2013 6:20 AM, "Christopher" 
wrote:

> How much is it going to cost ? My arm and leg, which are in good condition
> :)
>
> Christopher
>
> Emilio Hernandez wrote:
>
>> Redshift 3d
>>
>

Camera distance to an object

[Emilio Hernandez]

Hello I am trying to rig the camera DOF so I can attach the distance to a
null.  I am the ICE distance between node.  But when I turn on the distance
to output camera from the viewer, it gives me a different result.

So the Distance to output camera from the viewport options is different
than the Distance between node in the ICE tree using the kine.global.pos
from the camera and the null.

I will appreciate any help on this issue.

--

Re: Softimage 2014

[Sebastien Sterling]

That would be Splendid Ahmidou !!! i would owe you a debt in the afterlife !


On 29 March 2013 08:40, Ahmidou Lyazidi  wrote:

> That's why I talked about workarounds, and I'm not talking about ICE here.
>
> When I started my brush I was a C++ newbie, but now I'm sure it's just a
> matter of a few days, it's really not that complicated, I'll try to
> finish/improve it a soon as my contract is finished and release it for free.
>
> anyway, I only found this about max brush, I can't find any tolopology
> brush modifier:
>
> http://docs.autodesk.com/3DSMAX/15/ENU/3ds-Max-Help/index.html?url=files/GUID-CA6D812A-C92B-4037-8810-E0257C6B61AE.htm,topicNumber=d30e127452
>
> and this:
>
> http://docs.autodesk.com/3DSMAX/15/ENU/3ds-Max-Help/files/GUID-C87493C2-6E85-4DCB-A0AC-F355A9AA174F.htm
> that can be replaced by this in SI: https://vimeo.com/41703655#at=0
>
> you can as Piotrek for his swim uvs:
> https://vimeo.com/46540432
>
>
> Cheers
> ---
> Ahmidou Lyazidi
> Director | TD | CG artist
> http://vimeo.com/ahmidou/videos
>
>
> 2013/3/29 Matt Lind 
>
>> I think the point is that many of these features are not readily
>> available out of the box.  We have to write the tools ourselves and there
>> are many blockades to getting the job done.
>>
>> ** **
>>
>> I have the ICE compound Guillame LaForge sent out last year, but it’s a
>> bit hit and miss.  We’re not supporting ICE in our pipeline yet due to
>> instability when using ICE on reference models.  80% of our content is
>> referenced models.  I cannot let ICE compounds run amok in scenes that
>> become referenced models and are reused in hundreds of other scenes.  We
>> don’t have the bandwidth to manage such a situation.
>>
>> ** **
>>
>> Paint – Softimage is light years behind everybody else.  That is the
>> point.  Their animation-first mindset has been an obstacle to developing a
>> pipeline as the parts we need most are modeling and texturing.  Animation
>> is nice, but it too lacks a lot of tools and workflows expected out of the
>> box.
>>
>> ** **
>>
>> Max does have tools to modify topology as our character artist showed me
>> the tools a year or so ago spurring me to request the same from Softimage.
>> They had the ability to pinch and pull, displace, as well as cut into the
>> mesh almost like Zbrush.  ZBrush was definitely more robust, but what Max
>> offered was enough for what we needed to do.  I’m not a Max user, so don’t
>> ask me the names of the tools.  The best I can remember was something to do
>> with a graphite toolset and the brush has the ability to have operators
>> assigned to it so they could be painted on meshes.  It was intuitive –
>> something which softimage’s paint workflow is anything but.
>>
>>
>> Matt
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> *From:* softimage-boun...@listproc.autodesk.com [mailto:
>> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Ahmidou Lyazidi
>> *Sent:* Wednesday, March 27, 2013 4:32 PM
>>
>> *To:* softimage@listproc.autodesk.com
>> *Subject:* Re: Softimage 2014
>>
>> ** **
>>
>> Hi Matt, as you moved to 2013 lately, there might be workarounds for some
>> of you problems.
>>
>> *
>> Preserve UVs*: I think it's not publicly available, but piotrek did a
>> swim UVs for explicit using the custom tool SDK, so it's doable.
>>
>> *Pain*t: A Maya Artisan like paint tool is also possible, I have an
>> unfinished one, it's only doing push and smooth, but working, I also never
>> found the time to implement undo/redo.
>>
>> Also I'm not sure that maya and max have a brush to modify topology.
>>
>>
>> *Locking topology*: Since 2012 there is a pin UVs that survive to freeze.
>> I'm surprise that a all levels locked ICE tree can be freezed (bug?!),
>> but you ca still make an operator that will lock a point and all it's
>> attached properties.
>>
>> Locked operators are not freezable.
>>
>> ** **
>>
>> Cheers
>>
>> ---
>> Ahmidou Lyazidi
>> Director | TD | CG artist
>> http://vimeo.com/ahmidou/videos
>>
>
>

Re: Softimage 2014

[Ahmidou Lyazidi]

That's why I talked about workarounds, and I'm not talking about ICE here.

When I started my brush I was a C++ newbie, but now I'm sure it's just a
matter of a few days, it's really not that complicated, I'll try to
finish/improve it a soon as my contract is finished and release it for free.

anyway, I only found this about max brush, I can't find any tolopology
brush modifier:
http://docs.autodesk.com/3DSMAX/15/ENU/3ds-Max-Help/index.html?url=files/GUID-CA6D812A-C92B-4037-8810-E0257C6B61AE.htm,topicNumber=d30e127452

and this:
http://docs.autodesk.com/3DSMAX/15/ENU/3ds-Max-Help/files/GUID-C87493C2-6E85-4DCB-A0AC-F355A9AA174F.htm
that can be replaced by this in SI: https://vimeo.com/41703655#at=0

you can as Piotrek for his swim uvs:
https://vimeo.com/46540432


Cheers
---
Ahmidou Lyazidi
Director | TD | CG artist
http://vimeo.com/ahmidou/videos


2013/3/29 Matt Lind 

> I think the point is that many of these features are not readily available
> out of the box.  We have to write the tools ourselves and there are many
> blockades to getting the job done.
>
> ** **
>
> I have the ICE compound Guillame LaForge sent out last year, but it’s a
> bit hit and miss.  We’re not supporting ICE in our pipeline yet due to
> instability when using ICE on reference models.  80% of our content is
> referenced models.  I cannot let ICE compounds run amok in scenes that
> become referenced models and are reused in hundreds of other scenes.  We
> don’t have the bandwidth to manage such a situation.
>
> ** **
>
> Paint – Softimage is light years behind everybody else.  That is the
> point.  Their animation-first mindset has been an obstacle to developing a
> pipeline as the parts we need most are modeling and texturing.  Animation
> is nice, but it too lacks a lot of tools and workflows expected out of the
> box.
>
> ** **
>
> Max does have tools to modify topology as our character artist showed me
> the tools a year or so ago spurring me to request the same from Softimage.
> They had the ability to pinch and pull, displace, as well as cut into the
> mesh almost like Zbrush.  ZBrush was definitely more robust, but what Max
> offered was enough for what we needed to do.  I’m not a Max user, so don’t
> ask me the names of the tools.  The best I can remember was something to do
> with a graphite toolset and the brush has the ability to have operators
> assigned to it so they could be painted on meshes.  It was intuitive –
> something which softimage’s paint workflow is anything but.
>
>
> Matt
>
> ** **
>
> ** **
>
> ** **
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Ahmidou Lyazidi
> *Sent:* Wednesday, March 27, 2013 4:32 PM
>
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: Softimage 2014
>
> ** **
>
> Hi Matt, as you moved to 2013 lately, there might be workarounds for some
> of you problems.
>
> *
> Preserve UVs*: I think it's not publicly available, but piotrek did a
> swim UVs for explicit using the custom tool SDK, so it's doable.
>
> *Pain*t: A Maya Artisan like paint tool is also possible, I have an
> unfinished one, it's only doing push and smooth, but working, I also never
> found the time to implement undo/redo.
>
> Also I'm not sure that maya and max have a brush to modify topology.
>
>
> *Locking topology*: Since 2012 there is a pin UVs that survive to freeze.
> I'm surprise that a all levels locked ICE tree can be freezed (bug?!), but
> you ca still make an operator that will lock a point and all it's attached
> properties.
>
> Locked operators are not freezable.
>
> ** **
>
> Cheers
>
> ---
> Ahmidou Lyazidi
> Director | TD | CG artist
> http://vimeo.com/ahmidou/videos
>