phong Posted February 21, 2010 Share Posted February 21, 2010 Hi! I'm emtting particles from a texture using the pic() expression and have two questions concerning this approach. 1. Emission distribution seems to be dependent on primitive attributes which makes one require a relatively highresolution geometry to be able to represent the emissionmap with all it's details. Is there any way to tell the source node to check in the image itself what value it has at that position instead of looking it up in the primitive variables? 2. When using texture lookups via pic() emission gets INCREDIBLY slow. Takes a few minutes to cook 24 frames. Is there any way to improve this? Thanks a lot, Phong Quote Link to comment Share on other sites More sharing options...
jujoje Posted February 21, 2010 Share Posted February 21, 2010 (edited) Hey, I've also found that using the pic() expression gets frustratingly slow. Have you tried using a vopsop to transfer the texture to the geometry? It's usually much much faster so unless there's any particular reason for using the pic() expression then I'd definitely suggest going with vops. Hip file attatched * *below Edited February 21, 2010 by jujoje Quote Link to comment Share on other sites More sharing options...
jujoje Posted February 21, 2010 Share Posted February 21, 2010 The file! color_vopsop.hipnc Quote Link to comment Share on other sites More sharing options...
phong Posted February 21, 2010 Author Share Posted February 21, 2010 The file! Cool, this is about a MILLION times faster than the pic() expression! The tex() expression is kinda fast too, but for some reason doesn't display the images correctly. But how do I use this to control emission precisely now? I could promote the Cd attribute to pipe it into distribution, but then I'd have to rely on primitive attributes which requires an insanely high resolution geometry right? Cheers, Phong Quote Link to comment Share on other sites More sharing options...
jujoje Posted February 21, 2010 Share Posted February 21, 2010 To be honest I'm not entirely sure how your going to avoid using some pretty high resolution geometry, as the accuracy is reliant on mesh resolution. Rather than promoting the attributes from point to primitive and then using them as an area map in the pop network, you could just use a colour channel (e.g. $CR) in the birth probability of the pop networks source node. This should be a bit faster than having to promote the attributes, and should give you a bit more detail. I gave it a quick go on a 200x200 mesh and seemed pretty responsive. So unfortunately not really a solution, but hopefully should speed it up a fair bit. I'd be interested to know if you find a faster way of doing it. color_vopsop_cr.hipnc Quote Link to comment Share on other sites More sharing options...
phong Posted February 22, 2010 Author Share Posted February 22, 2010 Cool, it works pretty good now, although having a high resolution mesh is not really practical if there are dozens of emitting surfaces.. but with a lot of baking that should work! A different question, I know that in DOPs I can define a volume for a force to attenuate, is there anything like it in POPs or do I have to use a switch and expressions? Thanks man! You've been a big help to me! Phong Quote Link to comment Share on other sites More sharing options...
phong Posted February 22, 2010 Author Share Posted February 22, 2010 Just tried emission with distribution attribute 'area'. Didn't work, no particles get emitted when I pipe in a custom color map into the 'area' parameter in VOPs and promote it to primitive attribute in SOPs. If I set it to 1 instead emission works fine but over the entire geometry. Quote Link to comment Share on other sites More sharing options...
phong Posted February 22, 2010 Author Share Posted February 22, 2010 distribution works now. used negate in vop which cause some illegal values to occur. Quote Link to comment Share on other sites More sharing options...
sam.h Posted February 23, 2010 Share Posted February 23, 2010 I usually give the popnet a set of points to emit from if I want to control the emission like that. Using a set of points scattered on a geometry is really useful if you effect needs to be mesh res. independent. like: your geo > scatter > texture lookup > delete points you don't want to emit from. Then in the popnet just emit from points ordered and set the impulse birth amount to $NPT. I can make an example scene if I didn't make any sense ... Quote Link to comment Share on other sites More sharing options...
phong Posted February 23, 2010 Author Share Posted February 23, 2010 That makes sense indeed! How is the performance if the whole surface is covered with scattered points? Wouldn't that be slower than using a highRes mesh because there are more points than vertices required for a highRes geometry? Phong Quote Link to comment Share on other sites More sharing options...
sam.h Posted February 23, 2010 Share Posted February 23, 2010 I have kinda been assuming that it is faster since there is a lot less data in a point cloud, a mesh would have all of the connectivity data and stuff. Also the scattered positions are going to have to be generated in the popnet anyway ... For optimisation you could lookup the texture on the low res mesh and delete parts of the mesh before scattering. Quote Link to comment Share on other sites More sharing options...
aracid Posted February 23, 2010 Share Posted February 23, 2010 Hey all yeah the pic function is currently buggy, I reported this problem with sesi a while ago and they confirmed the problem and they suggested using vop's as a solution. Quote Link to comment Share on other sites More sharing options...
PhasmaCeritus Posted March 27, 2010 Share Posted March 27, 2010 Hey guys, awesome topic I just have a question: How do I use animated texture in texture lookup VOP? Thanks a lot Quote Link to comment Share on other sites More sharing options...
PhasmaCeritus Posted March 27, 2010 Share Posted March 27, 2010 Hey guys, awesome topic I just have a question: How do I use animated texture in texture lookup VOP? Thanks a lot ok sorry - figured out that if somebody is wondering one of the ways to do that is to create a detail string attribute (frame based file path) in SOP level on the object you are connecting to the VOP SOP and then import this as a parameter in VOP level. cheers Quote Link to comment Share on other sites More sharing options...
faulknermano Posted October 15, 2012 Share Posted October 15, 2012 (edited) Hey, I've also found that using the pic() expression gets frustratingly slow. Have you tried using a vopsop to transfer the texture to the geometry? It's usually much much faster so unless there's any particular reason for using the pic() expression then I'd definitely suggest going with vops. Hip file attatched * *below I've noticed that in taking the VOPSOP route the colormap node is used. But what if an image sequence is needed? the colormap node seems to generate an 'time-dependent' error. Is there a way to circumvent this? EDIT: answered above... (what a dork I am) Edited October 15, 2012 by faulknermano Quote Link to comment Share on other sites More sharing options...
sam.h Posted October 15, 2012 Share Posted October 15, 2012 You can use a Parameter node, you just can't put a time dependent expression inside the vopsop. Just put your expression on the outside of the vopsop. You don't have to have a detail attribute! Quote Link to comment Share on other sites More sharing options...
R_cyph Posted March 18, 2013 Share Posted March 18, 2013 (edited) I'm trying to use an animated ramp from COPS to emit from. But for it only does texture lookup in the colormap node for the vopsop once instead of everyframe. the colormap string is promoted but its still not reading in the cop every frame. Pretty please help! color_vopsop_cr_ANIMCOP.hipnc Edited March 18, 2013 by R_cyph Quote Link to comment Share on other sites More sharing options...
R_cyph Posted March 18, 2013 Share Posted March 18, 2013 pretty please Quote Link to comment Share on other sites More sharing options...
tjeeds Posted March 18, 2013 Share Posted March 18, 2013 Wow, that just will not update, will it? Weirdest part is that the cop node is making the vopsop time dependent. op: works fine to read deforming geometry nodes, seems like a bug. Quote Link to comment Share on other sites More sharing options...
xmetallicx Posted March 19, 2013 Share Posted March 19, 2013 (edited) Hey there!, there try adding "[$F]" to your color map. "op:/img/comp1/ramp1[$F]" This will force it to cook on every frame - Joel Edited March 19, 2013 by xmetallicx Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.