primvars and alembic export

[Simon Bunker]

Hi

Does Gaffer have a way of attaching primitive variables to geometry? And where is the source code for the procedurals which output the geometry so I can see what they are doing?

And also is it possible to export an Alembic file from Gaffer? Not that I see it happening a lot, but it might be nice to have the option of doing layout inside Gaffer.

thanks

Simon

[ben toogood]

I believe the newly added osl geometry shaders are intended to provide primvar generation. The idea being that in addition to writing pixel colours,  osl networks can be used to write per vertex attributes. Not sure what state the osl stuff is in though - John?

As for writing alembic files, if memory serves me there is a basic 'SceneWriter' node - but it may only output .scc files rather than .abc
Also, I think it was a bit of a prototype and isn't actually available from the node menu, so you'd have to create one via the script editor....

--
You received this message because you are subscribed to the Google Groups "gaffer-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gaffer-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Dresser]

> And where is the source code for the procedurals which output the geometry so I can see what they are doing?

There are some comments from John in this thread about writing procedurals that are probably a good place to start:
https://groups.google.com/d/msg/gaffer-dev/l6b_rA4UCiU/dF0RP7edBZ4J

> Does Gaffer have a way of attaching primitive variables to geometry?

Yeah, I think John's OSL stuff is going to be the way to do complex primvar manipulation.  But there are probably also some basic nodes missing for creating constant primvars or renaming things.  It looks like all you can do at the moment is delete primvars.

> And also is it possible to export an Alembic file from Gaffer?

Not at the moment - .scc scene export is in a prototype phase, and Alembic support is behind .scc.

-Daniel

[Simon Bunker]

On Wed, Mar 19, 2014 at 4:24 PM, Daniel Dresser <dres...@gmail.com> wrote:

> And where is the source code for the procedurals which output the geometry so I can see what they are doing?

There are some comments from John in this thread about writing procedurals that are probably a good place to start:
https://groups.google.com/d/msg/gaffer-dev/l6b_rA4UCiU/dF0RP7edBZ4J

Thanks I'll take a look at that. 

> Does Gaffer have a way of attaching primitive variables to geometry?

Yeah, I think John's OSL stuff is going to be the way to do complex primvar manipulation.  But there are probably also some basic nodes missing for creating constant primvars or renaming things.  It looks like all you can do at the moment is delete primvars.

That's the only one I could find too. I am glad I am not going crazy! What sort of complex primvar manipulations are you talking about? I would have thought sticking a bit of data to an object was a pretty simple operation isn't it? I also don't care about per vertex data right now - although it would be great to have the option. 

 

> And also is it possible to export an Alembic file from Gaffer?

Not at the moment - .scc scene export is in a prototype phase, and Alembic support is behind .scc.

Fair enough. It's not that high priority for me, but good to know it is on the radar.

 

-Daniel

[Andrew Kaufman]

If you just need simple data associated with an object, then maybe you don't actually need to manipulate prim vars. Try using attributes instead. Attributes are arbitrary data that get associated with a given location. See the StandardAttributes node for examples, and CustomAttributes to create your own.

I attached an image adding a bool and color to a sphere. These attributes are time varying per location, but can not vary per vert/poly of the object at that location.

Hope that helps.

Andrew

[Daniel Dresser]

There are cases where you would probably want a primvar rather than an attribute, and it could be handy to have a simple node for adding const primvars.  ( We do have one of these in the old modproc at IE ).

As for what we mean by complex primvar manipulations, basically think Houdini VOP SOPs - this is a much more complicated topic, but it would be pretty cool.

-Daniel

[john haddon]

I've stuck together a little pull request for a new PrimitiveVariables node which makes it dead easy to add an arbitrary number of arbitrarily typed primvars to an arbitrary set of objects :

https://github.com/ImageEngine/gaffer/pull/791

The OSL stuff is beginning to take pretty good shape now too. Previously the OSL processing node could only write to the P primitive variable, but it can now read from and write to arbitrary variables (for now, they must have vertex interpolation though). I've also just turned on an OSL "make-it-faster" option which I had overlooked before, which along with some of the optimisation that went into version 0.92.0 is making the speed feel fairly reasonably.

As far as understanding how Gaffer outputs to different renderers, there are a couple of things you'd want to look at. First off, the SceneProcedural class is what examines the gaffer scene and makes the calls to describe the scene to the renderer :

https://github.com/ImageEngine/gaffer/blob/master/include/GafferScene/SceneProcedural.h

https://github.com/ImageEngine/gaffer/blob/master/src/GafferScene/SceneProcedural.cpp

Secondly, the need to know that the SceneProcedural doesn't talk directly to Arnold or 3delight (or whatever), but instead talks to an implementation of the Cortex Renderer interface :

https://github.com/ImageEngine/cortex/blob/master/include/IECore/Renderer.h

That interface is then implemented for the actual renderer in question, so to see the final translation to Ri or Ai or GL calls, you need to take a look at the code in IECoreRI, IECoreArnold and IECoreGL respectively.

Hope that helps…

Cheers…

John

[ben toogood]

What sort of complex primvar manipulations are you talking about?

 

One thing that I'm interested to try at some stage is generating compression/tension info to drive dynamic displacement maps within Gaffer.  John's suggested that it could be possible (one day) to perform edge length comparisons between a 'deformed' mesh and a 'rest' mesh, then average values and write them on to the deformed mesh as primvars.

The OSL stuff is beginning to take pretty good shape now too. Previously the OSL processing node could only write to the P primitive variable, but it can now read from and write to arbitrary variables (for now, they must have vertex interpolation though). I've also just turned on an OSL "make-it-faster" option which I had overlooked before, which along with some of the optimisation that went into version 0.92.0 is making the speed feel fairly reasonably.

With that in mind John - any chance of a public build for 0.92.1 ?

--
You received this message because you are subscribed to the Google Groups "gaffer-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gaffer-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

ben tooogood

[john haddon]

On Thursday, March 20, 2014 12:01:35 AM UTC-7, ben toogood wrote:

What sort of complex primvar manipulations are you talking about?

 

One thing that I'm interested to try at some stage is generating compression/tension info to drive dynamic displacement maps within Gaffer.  John's suggested that it could be possible (one day) to perform edge length comparisons between a 'deformed' mesh and a 'rest' mesh, then average values and write them on to the deformed mesh as primvars.

This example is an interesting one - in C++ nodes it's easy to access the topology information and access data for arbitrary vertices, so computing the compression is straightforward. OSL shaders on the other hand are run strictly on a point-by-point basis, without access to other points. My idea is to implement the OSL pointcloud_search() shadeop with a special point cloud name of "connectedVertices" to allow an OSL object processor to access topology information. That should open up some interesting options for scripted deformers without forcing people to learn C++.

The OSL stuff is beginning to take pretty good shape now too. Previously the OSL processing node could only write to the P primitive variable, but it can now read from and write to arbitrary variables (for now, they must have vertex interpolation though). I've also just turned on an OSL "make-it-faster" option which I had overlooked before, which along with some of the optimisation that went into version 0.92.0 is making the speed feel fairly reasonably.

With that in mind John - any chance of a public build for 0.92.1 ?

We are overdue for a public build, but there's a couple of things I'd like to sneak in first (the make-it-faster option being one of them). Maybe 0.93.0?

[Simon Bunker]

 The OSL stuff you are doing does sound interesting - it sounds very much like Houdini VEX except for (ironically) shading. But my needs are much more modest - this new node looks like exactly what I want.

Thanks!

Simon

On Thu, Mar 20, 2014 at 1:50 AM, john haddon <thehad...@gmail.com> wrote:

[john haddon]

On Friday, March 21, 2014 4:47:43 AM UTC-7, Simon Bunker wrote:

 The OSL stuff you are doing does sound interesting - it sounds very much like Houdini VEX except for (ironically) shading.

It is ironic indeed. I started my osl-as-expression-language tinkering as a way of exploring OSL without access to an OSL renderer, in the hopes that one day Arnold and 3delight might jump on the bandwagon. Now Cycles and Appleseed are supporting OSL we do actually have the opportunity to do some shading so hopefully it will all come together in some form or other. I've already got an incredibly basic Cycles exporter on the go, which last night supported shader networks for the first time :

https://github.com/johnhaddon/gafferCycles

I'm developing this separately as a quick-and-dirty way of testing out Cycles - it's not the sort of code that's suitable for inclusion into Gaffer…

Cheers…

John

[john haddon]

On Friday, March 21, 2014 4:47:43 AM UTC-7, Simon Bunker wrote:

 The OSL stuff you are doing does sound interesting - it sounds very much like Houdini VEX except for (ironically) shading.

[ben toogood]

John - are the blender chaps distributing binaries of cycles yet? Or are you building that from source too?

Would you one day imagine shipping cycles along with gaffer (and does the license permit that)?

--

You received this message because you are subscribed to the Google Groups "gaffer-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gaffer-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

ben tooogood

[john haddon]

I'm not sure about the first question, but I'm building from source anyway - I needed to make a couple of tweaks to make it all work. I've just submitted a patch to the Cycles team so hopefully that can get rolled in soon, and binaries could become a possibility.

As far as licensing goes, Cycles uses the Apache license now, so it would be OK to ship it linked with Gaffer - I'm not sure that that's what we'd actually do in practice though. I definitely want Gaffer to have strong support for at least one open source renderer, but as one of the key features of Gaffer is renderer-agnosticism I'm not sure about tying the two together so strongly as to ship them together - I would hate to get into a situation where integrating other renderers is hard because Gaffer has an internal renderer with special privileges. So I think I'd imagine it more like it is for 3delight and Arnold now - we'd ship Gaffer with all the modules necessary for talking to Cycles, but Cycles itself would be downloaded separately. That would allow the two projects to keep to their own release cycles (chortle)…

I should also emphasise that the jury is still out as to which open source renderer is the right one to bet on - hence my fairly hacky approach to testing Cycles. It's easy to rule out a lot of them based on either incompatible licensing or lack of deformation motion blur, which I think leaves pretty much just Cycles and Appleseed (although I'd be interested if anyone wants to recommend other contenders). Cycles seems pretty far ahead in terms of features, but Appleseed seems ahead in terms of standalone-renderer-ness and having-an-api-ness...

Cheers…

John

[Simon Bunker]

Hi John

This definitely sounds like the way forward - keep the renderer separate, but provide all the hooks into it in Gaffer. I actually joined the appleseed mailing list because I saw some posts from you on there. The Cycles integration seems like a great start. I was wondering how hard it would be to add Cycles XML output support, but I have been put off from building standalone Cycles. I would love to see more binaries released.

If you go crazy you could probably extend OSL even further - eg build a crowd system with closures for different animation cycles. OSL is just a recipe for blending operations together after all. Larry would also need to create a Stupid OSL tricks Siggraph session!

thanks

Simon