Re: Autodesk Masters

[Adam Sale]

H...in the fine print is it?
Perhaps a statute of limitations based on the wearer outgrowing the jacket?
:-)


On Mon, Aug 13, 2012 at 8:57 PM, Upinder Dhaliwal wrote:

> Voted and best of luck. You should post a photo with that jacket [?]
> *--
> Upinder Dhaliwal*
> www.upinderdhaliwal.com
>
>
>
>
>
> On Tue, Aug 14, 2012 at 3:48 AM, Mirko Jankovic <
> mirko.janko...@aeonproduction.com> wrote:
>
>> done, wanna see photo with that jacket ;) good luck :)
>>
>
>
<<328.png>>

Re: Autodesk Masters

[Upinder Dhaliwal]

Voted and best of luck. You should post a photo with that jacket [?]
*--
Upinder Dhaliwal*
www.upinderdhaliwal.com




On Tue, Aug 14, 2012 at 3:48 AM, Mirko Jankovic <
mirko.janko...@aeonproduction.com> wrote:

> done, wanna see photo with that jacket ;) good luck :)
>
<<328.png>>

RE: Frezze ICE-UVs to TextureEditor

[Chris Chia]

The crash happens when you are projecting a planar texture on an Empty mesh.
I will log that as a defect, as it shouldn't crash XSI.

Chris

From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Vincent Ullmann
Sent: Tuesday, August 14, 2012 5:40 AM
To: softimage@listproc.autodesk.com
Subject: Re: Frezze ICE-UVs to TextureEditor

@Matt:
Sounds meaningful.
But one of my Tests today shoed me that this seems not to be the case.

i did:
- Get Empty Mesh
- Apply ICETree (Create Topo-Part)
- Freeze
- Planar TextureProjection
- Freeze
- Apply ICETree (Create UV-Part)
- Freeze
- Freeze
- Freeze
- [..]
- Open TextureEditor -> Crash


@Oleg:
Thanks! Your Script worked for me.
I got a little look inside and it seems to be the same thing Fabricio did in 
his Bake-UV-Script. Got no Idea where is the big diffrence.
Thanks again
<>

Re: Frezze ICE-UVs to TextureEditor

[Vincent Ullmann]

@Matt:
Becouse i need a UV-Cluster to apply my ICE-Actions somewhere.

ICE is not build to create new Objects.
Of course you could build new Topology, UV-Values, Particles, etc , but
"never" new Meshes, PointClouds, Nulls, Clusters, UVSets, etc...
please correct me if im wrong


@Oleg:
Probably thats it.
Copying the Topo with ICE may really only copy the raw Topology.
So it gets quite stable. I even was able to Skip the Last "Freeze"-Comand
in your script and hold the UV-Transfer live. So i could modify my ICE-Tree
and see the result live* in the TextureEditor
(Not realy live becouse it always need a click on the RefreshButton.)

I saw all your other stuff in the script you send me. For my final version
i will shrink it, so that it really fit my needs. Or even write the 3
necessary lines on my own. ^^

RE: Frezze ICE-UVs to TextureEditor

[Matt Lind]

Why are you creating a planar projection if you're creating UVs via an ICE tree 
in a later step?

Matt



From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Vincent Ullmann
Sent: Monday, August 13, 2012 2:40 PM
To: softimage@listproc.autodesk.com
Subject: Re: Frezze ICE-UVs to TextureEditor

@Matt:
Sounds meaningful.
But one of my Tests today shoed me that this seems not to be the case.

i did:
- Get Empty Mesh
- Apply ICETree (Create Topo-Part)
- Freeze
- Planar TextureProjection
- Freeze
- Apply ICETree (Create UV-Part)
- Freeze
- Freeze
- Freeze
- [..]
- Open TextureEditor -> Crash


@Oleg:
Thanks! Your Script worked for me.
I got a little look inside and it seems to be the same thing Fabricio did in 
his Bake-UV-Script. Got no Idea where is the big diffrence.
Thanks again

Re: Frezze ICE-UVs to TextureEditor

[Oleg Bliznuk]

I took a look on the Fabricio's script ( it has worked all times when I
used it before now btw ) and seems the problem is that he uses duplicating
the geometry while I use an empty one and set topo on it by ICEmodeling.
Since I need not only UVs but all stuff like normals and materials, I
prefer to use a truly raw approach on resulted mesh because there are too
many glitches with ICE topo and clusters ( which are actually a holy grail
of glitches and same because of it I have rebuilded Implosiafx on pure
ICEattributes that can be baked at any time if needed ) and more clean
input you have = more clean result you get.
-regards,
Oleg

Re: Frezze ICE-UVs to TextureEditor

[Sam Cuttriss]

Im with you on this one.
the bake uv scripts ive seen seem to just take temporarily apply an ice
tree and copy attributes.
no idea why that should be able to operate live.

_sam

Re: SDK : ShaderDefOptions default value, matrix

[Steven Caron]

sorry, yes i had a single dimension but i had a typo! so... code 18.

also i decided to use this instead...

m = XSIMath.CreateMatrix4()
m.SetIdentity()
paramOptions.SetDefaultValue(m.Get2())

sorry for the noise.
s

On Mon, Aug 13, 2012 at 3:00 PM, Matt Lind  wrote:

> It’s probably a single dimension array with 16 indices.
>
> ** **
>
> ** **
>
> Matt
>
> ** **
>
> ** **
>
> ** **
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Steven Caron
> *Sent:* Monday, August 13, 2012 2:58 PM
> *To:* softimage@listproc.autodesk.com
> *Subject:* SDK : ShaderDefOptions default value, matrix
>
> ** **
>
> has anyone tried to use a matrix44 input type on a custom shader? how do
> you set the default values?
>
> ** **
>
> i tried an 4 by 4 array of floats without luck. ideas?
>
> ** **
>
> s
>

RE: SDK : ShaderDefOptions default value, matrix

[Matt Lind]

It's probably a single dimension array with 16 indices.


Matt



From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Steven Caron
Sent: Monday, August 13, 2012 2:58 PM
To: softimage@listproc.autodesk.com
Subject: SDK : ShaderDefOptions default value, matrix

has anyone tried to use a matrix44 input type on a custom shader? how do you 
set the default values?

i tried an 4 by 4 array of floats without luck. ideas?

s

SDK : ShaderDefOptions default value, matrix

[Steven Caron]

has anyone tried to use a matrix44 input type on a custom shader? how do
you set the default values?

i tried an 4 by 4 array of floats without luck. ideas?

s

Re: Frezze ICE-UVs to TextureEditor

[Vincent Ullmann]

@Matt:
Sounds meaningful.
But one of my Tests today shoed me that this seems not to be the case.

i did:
- Get Empty Mesh
- Apply ICETree (Create Topo-Part)
- Freeze
- Planar TextureProjection
- Freeze
- Apply ICETree (Create UV-Part)
- Freeze
- Freeze
- Freeze
- [..]
- Open TextureEditor -> Crash


@Oleg:
Thanks! Your Script worked for me.
I got a little look inside and it seems to be the same thing Fabricio did
in his Bake-UV-Script. Got no Idea where is the big diffrence.
Thanks again

RE: Frezze ICE-UVs to TextureEditor

[Matt Lind]

Just a wild guess, but it sounds like an order of operations issue.  You're 
creating a texture projection on an empty polygon mesh which means it has zero 
size.  That would explain why the UVs are at (0,0,0) when you open the texture 
editor as they are initialized before the mesh exists.  Try making the texture 
projection after creating your topology.


Matt



From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Vincent Ullmann
Sent: Monday, August 13, 2012 12:57 PM
To: softimage@listproc.autodesk.com
Subject: Frezze ICE-UVs to TextureEditor

Hey,

currently i try to do some UVs in ICE.

In Terms of Viweport and Rendering everything seems to be ok, but when i try to 
open the TextureEditor Softimage always crashes.

Here are the steps i did:
- Get Empty PolygonMesh
- Create TextureProjection
- Freeze
- Create ICE-Tree
   - Create Topology in ICE
   - Create UVs in ICE (See Screenshot)
- [...]

Next, i would be great if i could Freeze my Mesh and do some further work 
but UVs arn't editable
I tried:
- Freeze M
- Freeze
- Merge with PrimitveCube and Transfer UVs (Give me Crash or Zeros UVs)

Did most of it in 2012 SAP.
In 2013 i'am able to Open the TextureEditor but all Values are (0/0) again.



I heard something about Freeze, Undo, Freeze again or so. But no success here. 
:(
Fabricio's Bake ICE UVs 
Script didnt 
help either.

Is there any "State of the Art-Solution" ?

Re: Autodesk Masters

[Bradley Gabe]

Wait a second Adam, if you've won a jacket I thought you don't get to vote.


On Mon, Aug 13, 2012 at 2:40 PM, Adam Sale  wrote:

> same here. Had to apply for a new area account... awaiting reply
> mail..
>
>

Re: Autodesk Masters

[Adam Sale]

same here. Had to apply for a new area account... awaiting reply mail..

On Mon, Aug 13, 2012 at 11:38 AM, Kai Wolter  wrote:

> waiting on my password reset mail to log back in and vote!
>
>
> On 13/08/2012, at 7:20 PM, Rob Chapman wrote:
>
> last time I logged in to the area was to vote a Softimage master as well
> :) gl to get a jacket!
>
> On 13 August 2012 19:08, Miquel Campos  wrote:
>
>> Done! ;)
>>
>>
>> 
>> 
>> Miquel Campos
>> *Character & Animation TD*
>>
>> Working at: www.shedmtl.com
>> Personal web: www.akaosaru.com
>> 
>> 
>>
>>
>>
>> 2012/8/13 Mirko Jankovic 
>>
>>> done, wanna see photo with that jacket ;) good luck :)
>>>
>>
>>
>
>

Re: Autodesk Masters

[Kai Wolter]

waiting on my password reset mail to log back in and vote!


On 13/08/2012, at 7:20 PM, Rob Chapman wrote:

> last time I logged in to the area was to vote a Softimage master as well :) 
> gl to get a jacket!
> 
> On 13 August 2012 19:08, Miquel Campos  wrote:
> Done! ;)
> 
> 
> 
> 
> Miquel Campos
> Character & Animation TD
> 
> Working at: www.shedmtl.com 
> Personal web: www.akaosaru.com
> 
> 
> 
> 
> 
> 2012/8/13 Mirko Jankovic 
> done, wanna see photo with that jacket ;) good luck :)
> 
> 

Re: Autodesk Masters

[Rob Chapman]

last time I logged in to the area was to vote a Softimage master as well :)
gl to get a jacket!

On 13 August 2012 19:08, Miquel Campos  wrote:

> Done! ;)
>
>
> 
> 
> Miquel Campos
> *Character & Animation TD*
>
> Working at: www.shedmtl.com
> Personal web: www.akaosaru.com
> 
> 
>
>
>
> 2012/8/13 Mirko Jankovic 
>
>> done, wanna see photo with that jacket ;) good luck :)
>>
>
>

Re: Autodesk Masters

[Miquel Campos]

Done! ;)




Miquel Campos
*Character & Animation TD*

Working at: www.shedmtl.com
Personal web: www.akaosaru.com





2012/8/13 Mirko Jankovic 

> done, wanna see photo with that jacket ;) good luck :)
>

Re: Autodesk aquires Naiad

[Ben Houston]

Yes, Houdini's FLIP solver is very similar to Naiad at a technological
level, but I am sure there are important details that differ between
the two implementations when it comes to speed and user interface.
-ben

On Mon, Aug 13, 2012 at 1:10 PM, Vincent Ullmann
 wrote:
> As long as i know, Naiad is some kind of Flip-Fluid-Based.
>
> Got a little talk to one of Naiads-Presenters who said that Markus
> Nordenstamm is pissed of Houdini becouse they are "inspired" by his
> Naiad-Fluid-Algorythm



-- 
Best regards,
Ben Houston
Voice: 613-762-4113 Skype: ben.exocortex Twitter: @exocortexcom
http://Exocortex.com - Passionate CG Software Professionals.

Re: Autodesk Masters

[Mirko Jankovic]

done, wanna see photo with that jacket ;) good luck :)

Re: Autodesk aquires Naiad

[Vincent Ullmann]

As long as i know, Naiad is some kind of Flip-Fluid-Based.

Got a little talk to one of Naiads-Presenters who said that Markus
Nordenstamm is pissed of Houdini becouse they are "inspired" by his
Naiad-Fluid-Algorythm

Re: Autodesk aquires Naiad

[Alan Fregtman]

Hi Ben,

Is Naiad FLIP-based? I thought it was a new algorithm.

On Mon, Aug 13, 2012 at 12:58 PM, Ben Houston  wrote:

> I think it is a good purchase as Autodesk is probably looking at
> Houdini which has an integrated FLIP solver.
> -ben
>
> On Mon, Aug 13, 2012 at 12:53 PM, adrian wyer
>  wrote:
> > http://usa.autodesk.com/adsk/servlet/pc/item?id=20307972&siteID=123112
> >
> >
> >
> > 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
> >
> >
>
>
>
> --
> Best regards,
> Ben Houston
> Voice: 613-762-4113 Skype: ben.exocortex Twitter: @exocortexcom
> http://Exocortex.com - Passionate CG Software Professionals.
>

Re: Autodesk aquires Naiad

[Ben Houston]

I think it is a good purchase as Autodesk is probably looking at
Houdini which has an integrated FLIP solver.
-ben

On Mon, Aug 13, 2012 at 12:53 PM, adrian wyer
 wrote:
> http://usa.autodesk.com/adsk/servlet/pc/item?id=20307972&siteID=123112
>
>
>
> 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
>
>



-- 
Best regards,
Ben Houston
Voice: 613-762-4113 Skype: ben.exocortex Twitter: @exocortexcom
http://Exocortex.com - Passionate CG Software Professionals.

Autodesk aquires Naiad

[adrian wyer]

http://usa.autodesk.com/adsk/servlet/pc/item?id=20307972

&siteID=123112

 

a

 

Adrian Wyer
Fluid Pictures
75-77 Margaret St.
London
W1W 8SY 
++44(0) 207 580 0829 


adrian.w...@fluid-pictures.com
mailto:adrian.w...@fluid-pictures.com> 

www.fluid-pictures.com
http://www.fluid-pictures.com/>  

 

Fluid Pictures Limited is registered in England and Wales.
Company number:5657815
VAT number: 872 6893 71

 

Excluding objects in lightmap rendering stage

[Rémi ARQUIER]

Hi list

I would like to know if it is possible to exclude objects in the ligtmap
rendering stage. Specificaly I would like that some of ICE particle clouds
not be seen by object beeing sampled (for reflection rays and shadow rays
for example).

I have tried combining a mip_rayswitch_stage plus a transparent shader for
the lightmapping rays on the particle material. It works, *but*, the
presence of the clouds considerably slow down the lightmap rendering stage
since the particles are still hit (by shadows and secondary rays and for
nothing). A "rendering lightmap visibilty flag" excluding the cloud for
real would be perfect, but doesn't seem to exist.

Any idea ?

I could write some custom MR shaders and custom plugins if necessary.

Thank you for help

Rémi

Re: Exponential slowdown on large particle emission

[Ciaran Moloney]

Try plugging the jitter emission along velocity node (taken from emit from
geometry) into your add point's execute on emit. Looks like that causes the
geometry to be evaluated multiple times (per-particle?)


On Mon, Aug 13, 2012 at 2:19 PM, Gustavo Eggert Boehs
wrote:

> The instantaneous update using generate sample set may be observed on a
> new scene with no previous caching.
> Im aware of Ciaran's SDF compound, which is really smart by the way... but
> my guess is that the emit node is doing something really silly, and I want
> to point that out, as it is the standard point creation method available in
> vanilla Softimage.
> Fact is the emit node is scaling exponantially while adding points from a
> sample set scales linearly, I do suggest you guys try this by yourselfs :)
>



-- 
- Ciaran

Re: Exponential slowdown on large particle emission

[Gustavo Eggert Boehs]

The instantaneous update using generate sample set may be observed on a new
scene with no previous caching.
Im aware of Ciaran's SDF compound, which is really smart by the way... but
my guess is that the emit node is doing something really silly, and I want
to point that out, as it is the standard point creation method available in
vanilla Softimage.
Fact is the emit node is scaling exponantially while adding points from a
sample set scales linearly, I do suggest you guys try this by yourselfs :)

Re: Exponential slowdown on large particle emission

[Rob Chapman]

yes, Volume emission has always been slow and never been improved since ICE
came out. see Ciairans sdf emit for the speed comparison - think it may be
quicker than default add point :)

http://blog.blackredking.org/?p=47



On 13 August 2012 13:27, Gustavo Eggert Boehs  wrote:

> Sorry for missing the specifics guys. (Yes) It was a volume emission, and
> this behaviour is better perceived when particles are created all at once.
> It is also important to notice, that once you have created the gazzillion
> particles, and waited for hours, if you try to do it again it does it all
> blazingly fast. At any rate, here are the steps to reproduce this:
>
> 1. Create a cube
> 2. With the cube selected, under ICE - Create, choose Basic Emission
> 3. Go to frame 2
> 4. Change the emission type to volume
> 5. Change Rate type to Total Number of Particles
> 6. Change the rate of particles to a very high number (say 3 million, or
> increase little by little get a feeling of the exponetional slowdown)
>
> 7. Repeat the volume point creation with a basic add point/generate sample
> set/iniate data and see how fast that works
>

Re: Exponential slowdown on large particle emission

[Ciaran Moloney]

Hi,
yes volume emission is slow. I guess that's just the nature of the problem,
especially since ICE volume emission is really accurate. You can get
quicker volume emission by generating lower resolution distance fields that
approximate the shape.

I'm just making an uninformed guess here, but I believe Softimage is
caching the emission volume, which is why you get an instantaneous update
using the generate sample set after having already emitted using the other
node. If the volume is already constructed then sample creation is easy.
Try emitting from a deforming geometry with time varying emission and you
shouldn't notice much difference at all.

Ciaran

On Mon, Aug 13, 2012 at 1:27 PM, Gustavo Eggert Boehs
wrote:

> Sorry for missing the specifics guys. (Yes) It was a volume emission, and
> this behaviour is better perceived when particles are created all at once.
> It is also important to notice, that once you have created the gazzillion
> particles, and waited for hours, if you try to do it again it does it all
> blazingly fast. At any rate, here are the steps to reproduce this:
>
> 1. Create a cube
> 2. With the cube selected, under ICE - Create, choose Basic Emission
> 3. Go to frame 2
> 4. Change the emission type to volume
> 5. Change Rate type to Total Number of Particles
> 6. Change the rate of particles to a very high number (say 3 million, or
> increase little by little get a feeling of the exponetional slowdown)
>
> 7. Repeat the volume point creation with a basic add point/generate sample
> set/iniate data and see how fast that works
>



-- 
- Ciaran

Per primitive data from Softimage to mental ray

[Rémi ARQUIER]

Hi all,

I would like to compute some per primitive data in Softimage and get it
back in a mental ray custom shader. I successfully tried the per object
data using UserDataBlob and a custom Operator + mi_query + miQ_INST_DATA (I
used the well documented ShowEdges example of the SDK documentation). But
now I would need *per triangle data*, if possible using the same way as the
ShowEdges example, i.e : with a custom OP.

The UserDataMap and the mi_query + miQ_PRI_DATA look goods but I didn't
find any example.

Any ideas / links ?

Many thanks

Rémi Arquier

Re: Exponential slowdown on large particle emission

[Gustavo Eggert Boehs]

Sorry for missing the specifics guys. (Yes) It was a volume emission, and
this behaviour is better perceived when particles are created all at once.
It is also important to notice, that once you have created the gazzillion
particles, and waited for hours, if you try to do it again it does it all
blazingly fast. At any rate, here are the steps to reproduce this:

1. Create a cube
2. With the cube selected, under ICE - Create, choose Basic Emission
3. Go to frame 2
4. Change the emission type to volume
5. Change Rate type to Total Number of Particles
6. Change the rate of particles to a very high number (say 3 million, or
increase little by little get a feeling of the exponetional slowdown)

7. Repeat the volume point creation with a basic add point/generate sample
set/iniate data and see how fast that works

RE: Exponential slowdown on large particle emission

[Chris Chia]

How did you setup your icetree?
I have created 3 million particles under 20secs (setting 1 million for Rate in 
No. of Particles Per Sec)

Chris

From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Gustavo Eggert 
Boehs
Sent: Monday, August 13, 2012 6:57 AM
To: SI mailing list
Subject: Exponential slowdown on large particle emission


I was just simulating 3 milion particles and noticed SI doing somethig very 
odd. If I create millions of particles by generating a sample set and adding 
points I get them almost instanenously (less than a seccond). Now when I use 
the regular emit node emmiting 3mil particles can take hours... HOURS.
Other numbers:
100.000 particles = 3 seconds
200.000 particles = 15 seconds
400.000 particles = 121 seconds!!

Anybody else getting this?
<>

RE: Particle collision behaves differently after particle count > 4000

[Chris Chia]

Hi Stefan,
Thanks for the repro steps and I am able to repro the crash.
As for "Why does the output type change at all? The instance is a piece of 
geometry just like the non-instanced sphere, or at least it should be 
interpreted like that", I will file this as an improvement.
Many thanks.

Chris

-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Stefan Kubicek
Sent: Sunday, August 12, 2012 3:39 PM
To: softimage@listproc.autodesk.com
Subject: Re: Particle collision behaves differently after particle count > 4000

Hi Chris,

here are the steps to reproduce:

1 Create a point cloud with an ice tree (simulated or not does not matter).
2 Create a sphere and make a model from it, make an instance of that model.
3 Create another sphere without a model, create a group with the second sphere 
as it's _only_ member.
4 In the ice tree of the point cloud, create an "Emit from Geometry" node, 
connect it to the ICE Tree's "Port 1".
5 From an explorer, drag the group containing the sphere into the point cloud's 
ICE tree  (Get Group node is created), plug it into the "Emitter 1" port of the 
Emit from Geometry node.
6 In the explorer, drag the model instance we created before into the group -> 
Soft crashes.

Thanks for looking into it. From what I can tell the Get Data node tries to 
adapt to the changing input data by changing the output data type. Something 
downstream doesn't seem to like that. The question is: Why does the output type 
change at all? The instance is a piece of geometry just like the non-instanced 
sphere, or at least it should be interpreted like that.

That seems to crash both 2012 and 2013. It seems nobody ever tried emitting 
particles from instanced geometry?

  Stefan


> Hi Stefan,
> Would you mind if you could share the 'group with model having referenced 
> iceteee' crash scene?
>
> And did you work on 2013SP1?
>
> Chris
>
>
> On 8 Aug, 2012, at 5:14 AM, "Stefan Kubicek"  wrote:
>
>> Guys,
>>
>> I just had a different hickup with the exact same setup where 
>> suddenly collision with one of my collision objects would suddenly 
>> not work anymore. After saving and reloading the scene it went back 
>> to normal behavior. Something _is_ afoul with Bullet RBD in ICE, see my 
>> other post from yesterday regarding different issues.
>>
>> And I just hit yet another one: When assigning an instanced model to a group 
>> thats already referenced in an ICE tree (e.g. as a GetData node from a drag 
>> and drop action from explorer into the ice tree) and that node is already 
>> connected to another node Softimage will bomb out to the CER form and then 
>> exit.
>> Correction: This one has nothing to do with Bullet RBD, it even happens with 
>> the basic "Emit from geometry" preset ICE Tree.
>>
>>> Hi,
>>> I've got a simple setup here with "Simulate Bullet Rigid Bodies", 
>>> where I'm trying to fill a volume with small spherical particles (radius 
>>> 0,1).
>>> Testing 2013SP1.
>>> As long as the particle count is below 4000 (for whatever reason), 
>>> particles tend to penetrate/clump.
>>> Suddenly at the frame where the count reaches 4000, all particles 
>>> push themselves out of their neighbours at once, then simulation 
>>> continues normally, with no penetrations.
>>> A bug? I didn't touch any simulation range settings.
>>>
>>> Video (possibly not converted yet):
>>> https://vimeo.com/47089050
>>>
>>> Scene:
>>> http://www.sendspace.com/file/c0xke5
>>>
>>> Thanks a lot!
>>> Eugen
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> ---
>> Stefan Kubicek   Co-founder
>> ---
>>  keyvis digital imagery
>> Wehrgasse 9 - Grüner Hof
>>   1050 Vienna  Austria
>>Phone:+43/699/12614231
>> --- www.keyvis.at  ste...@keyvis.at ---
>> --  This email and its attachments are --confidential and for the 
>> recipient only--
>>
>


--
---
Stefan Kubicek   Co-founder
---
   keyvis digital imagery
  Wehrgasse 9 - Grüner Hof
   1050 Vienna  Austria
 Phone:+43/699/12614231
--- www.keyvis.at  ste...@keyvis.at ---
--  This email and its attachments are
--confidential and for the recipient only--

<>

Re: Exponential slowdown on large particle emission

[Sebastian Kowalski]

by any chance via volume emission?


Am 13.08.2012 um 00:56 schrieb Gustavo Eggert Boehs :

> I was just simulating 3 milion particles and noticed SI doing somethig very 
> odd. If I create millions of particles by generating a sample set and adding 
> points I get them almost instanenously (less than a seccond). Now when I use 
> the regular emit node emmiting 3mil particles can take hours... HOURS.
> Other numbers:
> 100.000 particles = 3 seconds
> 200.000 particles = 15 seconds
> 400.000 particles = 121 seconds!!
> 
> Anybody else getting this?