search

wdas / SeExpr

SeExpr is an embeddable, arithmetic expression language that enables flexible artistic control and customization in creating computer graphics images. Example uses include procedural geometry synthesis, image synthesis, simulation control, crowd animation, and geometry deformation. https://wdas.github.io/SeExpr
https://www.disneyanimation.com/open-source/seexpr/
Other
405 stars 86 forks source link

deprecated: Expression::getLocalVars() #60

Closed sosh closed 5 years ago

sosh commented 8 years ago

In the previous version of SeExpr we were able to get a list of variables that were defined locally in the expression and we would use that list to add new point attribute and set it's value during the expression evaluation. I haven't found an alternative way to access those variable names. The 'resolveVar()' function does not list those variables. Is there an alternative way to do this?

jberlin commented 8 years ago

I don't see support for this anymore, but I'm not sure why it was removed. @aselle -- do you have any context for why this change was made?

aselle commented 8 years ago

getLocalVars() makes significantly less sense in the presence of jit compilation. intermediate variables used to always be created as C++ objects. Now that we JIT compile, intermediate variables might never be created, might be constant folded, etc.

The recommended way to go around this is to use SeExpr/VarBlock.h. The idea is to declare variables as part of a block. Then any group of expressions that use that block can read from any variable in that block. Each expression run can target one of those block variables as a destination. It's not quite the same, but using the VarBlock stuff will give you much more performance and is recommended.

I don't think there is an example on how to do this, but I can give you more suggestions if you have more questions...

sosh commented 8 years ago

Thank you both for your quick response. Yes, it totally make sense now that you would remove this function because of the JIT compile. I was looking at the VarBlock but it wasn't clear to me how I could use it. It would be great if there was a least a sudo example as part of the documentation.

We have been using SeExpr library in Katana for the past few years to manipulate incoming geometry point/primitive attributes or to add new attributes. I was looking forward to add support for matrix and string attributes manipulation with this new revision. The idea was to expand this Katana Op to be somewhat similar to houdini's attributeWrangler nodes as we add other custom functions.

I would appreciate any hint on how to use the VarBlock.

On Fri, Sep 9, 2016 at 5:25 PM, Andrew Selle notifications@github.com wrote:

getLocalVars() makes significantly less sense in the presence of jit compilation. intermediate variables used to always be created as C++ objects. Now that we JIT compile, intermediate variables might never be created, might be constant folded, etc.

The recommended way to go around this is to use SeExpr/VarBlock.h. The idea is to declare variables as part of a block. Then any group of expressions that use that block can read from any variable in that block. Each expression run can target one of those block variables as a destination. It's not quite the same, but using the VarBlock stuff will give you much more performance and is recommended.

I don't think there is an example on how to do this, but I can give you more suggestions if you have more questions...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/wdas/SeExpr/issues/60#issuecomment-246074277, or mute the thread https://github.com/notifications/unsubscribe-auth/AAdeaNMUlK-XvkUfQdK0ffukTPvhmCfGks5qofjlgaJpZM4J5Oxy .

jberlin commented 7 years ago

@aselle -- I'm adding a VarBlock example into the imageEditor demo code. I'd like to clarify when to use SeExpr2::VarBlock and when to use SeExpr2::Context. Does VarBlock replace Context? We seem to use the Context for things like search path, but what else? My example code uses VarBlock for u,v -- is this appropriate or does it make more sense to use the Context for u,v? Is the VarBlock appropriate for locally declared vars as well as more global vars like u,v or frame?

Any insights are much appreciated!

aselle commented 7 years ago

Sorry for the delay on reply.

Context is not superceded by VarBlock. Varblock is only for numeric data that are first class types that can be evaluated in SeExpr. Context is a attr/value (string to string) store. In principal VarBlock could now store strings because it is a supported type, but I think Context is a separate concept and it should stay.

VarBlock should be where u, v are done.

davvid commented 5 years ago

It sounds like VarBlock is a supported solution so closing this issue for now. The VarBlockExample test case is a good place to look for example usage.