tallen

Yon, do you recall the reason for this? I am inheriting someones' setup and I'm getting the same subtle flickering. I'm thinking it's due to using a Cloud Light, which contains a volume arrival sop, because when I bypass the node and render, the flickering goes away. I cant change the setup (such as throwing out the cloud light and simply increasing volume bounces in mantra) so I'm wondering if you recall A) what the problem was, and if it's was the cloud light setup, than do you know what you did to fix it? I found out that increasing the convergence (tolerance) is helpful. -ta

Oops. nevermind... Thanks! (http://forums.odforce.net/topic/21989-bulletsop-2015)

Any update to this? I am delighted to see this in circulation.

oh hey... I was there at Imageworks doing dev on Green Lantern at Sony. The green energy was made three different ways: The light beam was created using a shader, although early tests were created via a myriad of techniques. One of them using volumetric splines common to both Sony (Svea) and DD (Storm). (That's something I'd like to see Sesi begin to embrace. It's been years overdue) The green energy balls fx (surrounding hal) were created predominately with particles and sprites (and instancing) - quite ram intensive (the still you provided had a ton of motion blur in there) And finally, Hal's fast and slow energy was done with geo tricks using facing (camera) ratio fade method. (Think 'trail sop' with 'connect as mesh' option, then 'alpha para' & 'alpha perp' in shading) Fun thing about Green Lantern is that much of the fx can be done with houdini (because most of it was!) But anyone who went to DD or Sony (or R&H) knows about volumetric splining. We could use that in the Sesi repertoire.

The kind folks at SESI have instructed me to use the Explicit Cache parameter located on a Dop Network. That, in conjunction with using the file dop (and saving as .sim), will allow the user to 'pick up' a sim that has crashed some between here and there. Really cool. I suggest you check it out. Thanks for all the help! -tom

Absolutely right. And I should explain because I think I just set everyone off on a wild goose chase. My apologies. I have a sim animating straight up and then falling down to the surface. The sim has already been cooked and so I'm only putting some additional pscale onto the particles.... So anyhew, at it's peak height, the particles need to be a bit larger than the rest of the particles so that when I mesh using the "Particle Fluid Surface" sop I get a smooth increase in scale based on taking the inverse square of $VY. (It works just fine as is and I moved on). But that night, at some point I felt it necessary to include $VX and $VZ so that I could possibly prevent any unwanted visual artifacts. I suppose I was thinking of something like using the length expression but somehow translating that to normalize?... What? Wow I can't even imagine at this point. Next time I need to re-visit this perhaps I'll do something like evaluating the length($VX,$VY,$VZ) first and then adding the inverse square... thanks everyone.

Thanks Alex, we'll give it another try. We actually tried it and got two (unsatisfactory) results. On the first attempt the sim just sat there for an hour which lead us to believe that the sim was in fact trying to recook all the previous frames. On the second attempt we just got what was probably a user error, so perhaps we'll try again, thanks. -tom

To anyone's' knowledge, is there any way to pick up a sim from some point halfway through the sim? Reason: A typical frustration with a farm render. It crashed... and we trying to pick it up where we left off. Can it be done? We tried picking it up from the last complete frame. No go. The sim seems to want to cook every preceding frame before the crash, which is of course hours long. Anyone have any luck with this? Some special way? Have to ask! thanks!

Pretty sure I have the inverse square of $VY below: 1/($VY^2+1) but I can't seem to be able to get the normalized inverse square of velocity. Any expression help please? thanks!

Digital Tutors.... reminded me that I should be going about it differently. Forgot about the offset $MAPU filmstrip approach (and not mess with any point attribute overrides!) For an eight image filmstrip cycle (static): Texture offset: ceil(fit01(rand$ID),0,7))/8 (in place of $STEXU) Texture Size: 1/8 (in place of $STEXW)

having troubles manipulating the texturepath of the sprite shader (param: sprite_baseColorMap) Trying to randonmize my renders a bit. I think I am getting tripped up with where the shader is being referenced. If I create a point (or any other class) attribute with the matching param name it doesn't recognize the attribute (override). To complicate, the sprite pop requires that you give a path to the shader. If I don't use the path, I can render with the shader for sure but i am assuming that I can no longer manipulate the material in sop? Confused. Any help from someone who has used this approach before? Just trying to have each sprite (particle) point to a few different texture maps...And I'd like to stick with the sprite shader.

Thanks Steven. I'll check it out soon. I ended up getting some help from the Ubuntu forums with getting the restricted driver manager working. Although I might like Envy better. But here's the support I received in case someone else has the same problem: In "System/Administration/Restricted Drivers Manager", if you can't enable ON the drivers... 1) Go to "System/Administration/Software Sources", and go to the first tab; check mark ON the "Proprietary drivers for devices (restricted)". You will most likely get a notice saying that the information about your software is outdated and in order to proceed, you need to download the updated drivers.Click the RELOAD button (Online connection required) 2) Go back to "System/Administration/Restricted Drivers Manager", and once again enable ON the restricted drivers. You should see the drivers being updated at this point. 3) Reboot. --------------- Houdini 9 HD appears to work fine now. (Well, at least it doesn't crash when creating particles with a count above 400.) I am curious however, to see what Envy has. ...Would be nice to have an interface to be able to manipulate some of the features of the card. I looked around on Mr. Milone's website, but I didn't see anything that implies that Envy handles that as well. Anyway, I'll load up Envy and check it out... Thanks again for the info!

I have recently installed Ubuntu 7.10 (for windows32) and I'm trying to install the x86 linux driver for my graphics card: the nVidia Quadro FX3000. In GNOME (default for Ubuntu) if you attempt to install, you get an error message and subsequent exit. Recommends something like: "You need to install the driver without x running..." So, nvidia recommends performing an init 3 (ie: no x11 running) but, I am having troubles getting to the recommended "runlevel 3". Any idea of how to get there? If I boot up in recovery mode, I am in "level 1", and again nVidia (upon install) says it's not a good idea and I should go to "runlevel 3"; so when I type init 3 (or init 2) I get kicked up to the full graphics level. So what gives? I tried looking for the /etc/inittab file to address this issue, but it doesn't seem that Ubuntu has that in it' os. Is there an appropriate init file I can edit somewhere? Also, it has been recommended that I should be using the Restricted Drives Manager and of course I did that first before doing the above. But, I am unable to use the restricted drives manager. I can't enable the nvidia drivers when I checkmark "ENABLE". No message error I can work with either. Just says something lame like: you have not enabled the drivers. (nice) Same problem when turning on Desktop Effects in System/Preferences/Appearance to full Desktop Effects. Same denial. Same lame error... Anyone come across that yet?