Jump to content

eloop

Members
  • Content count

    266
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by eloop

  1. Hi all, I'd like to get your opinions about how to go about doing the following. I want to write a new SOP (or perhaps OBJ) that provides an instance of a physical simulation that has a reasonably expensive startup and per frame cook time, but once its cooked it caches the results to be made available for that time step via custom vex functions that may be called in any of the various vex contexts. I've got it working at the moment where I can create a single instance of the simulation via a custom hscript command and my custom vex functions are returning the results but I'd like to do it in a way where I can have multiple copies of the simulation object each with different parameters (via the gui) and for the simulation objects to cook if the time has changed and I need the results from one of my vex functions. Is this the way to go about this type of thing ? What is the fastest way to get access from a vex function back to the SOP_Node derived instance where I have a reference to my simulation object ? I imagine that there is a similar mechanism for vex functions to get access to textures from cop nodes. Any suggestions appreciated. Thanks, Drew
  2. I'm beginning to see the problems now, it looks like I need to be caching a bunch of simulation results for different time steps / contexts. Perhaps I could keep my own cache that holds results for a set of different time steps with mutex protection from threads etc its all a bit risky without a clear idea about how this stuff is setup. I notice there is an OP_Cache class that may be useful. The same thing must be handled already for things like image cops that are being read in other contexts but its not obvious how it all hangs together at the hdk level and particularly when throwing vex into the mix as well. I think it's probably time to bail and just read in lots of floating point image files ... oh well. Time to step back and rethink. If the martian labs guys are using fft's to sum the wave field rather than using a simple sum of the waves / per position enquiry I'm impressed -Drew
  3. Hmm, I guess they are a bit similar, but I'm having fun re-implementing the Tessendorf FFT stuff from the Siggraph notes. Exposing things via vex just seemed to be the most flexible way to go about this as you aren't forced to create any geometry or images unless you really need them and you can easily use the results in any or all contexts without stripping attributes off of a different data type via expressions which would probably also be slower. The fact that the martian labs guys and DD have done this means that there must be a right way to go about it... A snapshot of the current state - ocean.jpg. Thanks, Drew
  4. Hmm, that one gets me a quick crash and it appears this would be cooking everytime the vex function is called whereas I really want a cook when we are at a different time. Is there a way for the vex call to register interest in a SOP such that it will ony recook when needed ? Perhaps I should just pass the time explicitly across to my sop in my eval_** calls and let the sop determine if it needs to run at for new timestep, in effect bypassing cooking ? If any sidefx developers are reading this I would appreciate a bit of help here ... should I go to a system where I bypass Operators as containers for the simulation and just interact with it via hscript commands and vex functions ? Thanks, Drew
  5. Ok, the following works. Now I have to work out how to make the sop cook when needed ... static void ocean_eval_uv(int, void *argv[], void *) { float *result = (float *)argv[0]; // lookup tho simulation sop SOP_Node *node = OPgetDirector()->getSOPNode((char *)argv[1]); if (node && node->getOperator()->getName() == "ocean") { drwOcean::Ocean *o = reinterpret_cast<SOP_Ocean*>(node)->getOcean(); float *u = (float *)argv[2]; float *v = (float *)argv[3]; *result = o->eval_uv(*u,*v); } else { *result = 0.5; } }
  6. Which is pretty much what I'm doing as well. I'm doing a Tessendorf style ocean wave simulation and I'd like to be able to use the various associated computed quantities via vex to generate displacement/bump and foam and perhaps birth some particles as well. At the moment I'm just doing the geormetry displacement with a pic() expression that references a VexCOP. I'd be interested in knowing how you make sure the sop has been cooked properly at the time when the vex function wants to access it. Thanks, Drew
  7. Hopefully it will work though and I think as long as the methods I'm calling on my SOP are re-entrant the multithreading should't cause any problems, in fact I would like it to work that way. I'm trying the following to find the operator from it's path name but it doesn't seem to be working as *op is being returned NULL. OP_Director *od = OPgetDirector(); OP_OperatorTable *table; OP_Operator *op; const char *path= "/img/img1/in"; od->getTableAndOperator(path,table,op); update: the following method of OP_Node seems to be what I want OP_Node *findNode(const char *path) const; -Drew
  8. Yes, this is all using the hdk, the hscript commands and the vex functions are c++ dso's. I want the vex functions to be returning results that are based on the simulation that is computed in the custom SOP. So I would like to have the vex function (written in c++) get a parameter that identifies the simulation SOP so that it can get access to its internals, and force it to cook if neccessary. I can probably just maintain my own std::map<char*,SOP_Node*> in the custom SOP such that the vex function can look it up using a string parameter everytime it runs. But I'm guessing that there is already a safe and optimized mechanism provided for doing this via the hdk so I am hoping someone may me able to point in the right direction ? -Drew
  9. Render: Polygons as SDS

    Yep, it was verified and logged by support . -Drew
  10. Render: Polygons as SDS

    This may be a bug with mantra barfing on displaced SDS's. I reported something similar a while back and to my knowledge it hasn't been fixed yet. You should probably report it to SideFX. -Drew
  11. Reading new posts

    I "view new posts", but what would be even better would be an RSS feed for that page. I've recently started using the ''Sage" rss plugin with Firefox and it is a great timesaver. No more loading pages to see if there is something new to read. One thing I'm using it for is tracking the OdWiki recent changes page, not that it's often that there is nothing new to read there -Drew
  12. I can't see your attachment. I just "exported" a zbrush tool as an OBJ and managed to bring it back in using a File SOP so I'm not sure what's going wrong for you. After loading the .obj you need to pipe it through a Reverse and a Facet to point consolidate with distance set to 0.0. -Drew
  13. opensource OpenEXR i/o

    Things like Liquid and mrLiquid would fall into that category so it seems possible. http://www.colindoncaster.com/tools/liquid.html http://sourceforge.net/projects/mrliquid/ -Drew
  14. opensource OpenEXR i/o

    Hi Jason, I'd be interested in using it And if I wasn't so snowed under I would like to help out ... I spoke to one of the sidefx guys about the possibility of this at the siggraph meeting this year and they were concerned how the openexr code would sit in the HDK universe since the openexr lib requires C++ exceptions enabled (and handled) whereas HDK doesn't, possibly a platform dependant problem that would need to be resolved. -Drew
×