Maya Bifrost procedurals
703 views
Skip to first unread message
Brian Meanley
Sep 19, 2018, 5:11:09 PM9/19/18
to gaffe...@googlegroups.com
I'm trying to get some Bifrost elements from Maya to render in Gaffer, but I'm running into a few issues at the moment that I'm hoping someone can shed some light on.
When I export the Bifrost data from Maya as an ASS file, I am able to load and render this in Gaffer just fine (using the Arnold Bifrost procedural that ships with Maya2018); however, If I try to by-pass the ass file, and just set up the ExternalProcedural node in Gaffer to read the BIF files directly, I consistently get IPR Arnold renders to crash. Just to be clear, Arnold loads the cache OK, and seemingly completes a single IPR render pass, but then crashes at the end. If doing a normal (non IPR) render, it appears to make it all the way through, and complete without a crash.
My first attempt was to simply mirror the parameters that are set in the Ass file, on the ExternalProcedural node, but I'm sure that I am mixing something up along the way.
The ass file looks something like this:
bifrost_volume
{
name aeroShape1
visibility 255
matrix
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
shader "aiStandardVolume1"
opaque off
matte off
step_size 0.0250000004
cache_folder [PATH TO SOME BIF CACHE DIR]
object "{\"QueryVersion\":\"1.0\",\"ActiveGraph\":\"_bifrostAero1_bifrostAeroContainer1__aero\",\"EvaluationID\":1101,\"ResourceID\":\"bifrost_sim\",\"filters\":[{\"operator\":\"&\",\"clauses\":[\"name=AeroObject\",\"type=AeroObject\"]}]}"
channels "vorticity"
velocity_scale 1
space_scale 1
fps 24
clip off
density_channel "density"
smooth 0
smooth_iterations 1
ignore_motion_blur on
}
Any advice or guidance in the right direction would be great!
Thanks!
-Brian
John Haddon
Sep 20, 2018, 3:32:16 AM9/20/18
to gaffe...@googlegroups.com
Hi Brian,
Not sure if this will help or not, but could you use an ArnoldRender node set to SceneDescription to write out the ass file corresponding to the direct loading of the BIFs in Gaffer? Comparing that to the original ass file out of Maya to see if there are any differences might be a good starting point...
Cheers...
John
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Brian Meanley
Sep 20, 2018, 1:55:10 PM9/20/18
to gaffe...@googlegroups.com
Hi John, thanks for the suggestion.
Exporting to an ass file was one of the first things that I looked at; however nothing seems to be out of the ordinary to me that I can tell.
I did run into a few other inconsistencies though, so I think I also need to do a bit more digging on our end as well. I thought that I was able to render the ass file version of the procedural just fine (and I can locally on my own machine); however, when I submit the gaffer job to our farm, I get the similar crashes to what I am seeing locally with the non-ass file version of the procedural (the render gets to 100%, then crashes, and fails to write out the image files).
Has anyone here successfully used the Bifrost procedural in gaffer yet?
Thanks for the input, I'll be sure to follow up if I discover anything new!
-Brian
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.
--
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.
Sachin Shrestha
Sep 20, 2018, 7:50:34 PM9/20/18
to gaffe...@googlegroups.com
I’ve not tried using the bifrost procedural in gaffer and this may be totally unrelated but from some prior experience with similar issues when using xgen procedural in the newer Arnold 5.x versions, the parallel node init seemed to be a problem for us then. Have you tried turning it explicitly off from the global (if that’s not off already) since the default is set to true in the new Arnold versions.
Brian Meanley
Sep 20, 2018, 8:04:15 PM9/20/18
to gaffe...@googlegroups.com
Hi Sachin,
Thanks for the suggestion!
Unfortunately, I've tried that as well, and it does not seem to change the outcome in my case.
-Brian
On Thu, Sep 20, 2018 at 4:50 PM Sachin Shrestha <noizf...@gmail.com> wrote:
I’ve not tried using the bifrost procedural in gaffer and this may be totally unrelated but from some prior experience with similar issues when using xgen procedural in the newer Arnold 5.x versions, the parallel node init seemed to be a problem for us then. Have you tried turning it explicitly off from the global (if that’s not off already) since the default is set to true in the new Arnold versions.
--
Sachin Shrestha
Sep 20, 2018, 8:07:04 PM9/20/18
to gaffe...@googlegroups.com
Sorry that didn’t help. Can you provide additional info like which Maya version, MtoA version, gaffer version and OS version are you using? I can try to reproduce this at work tomorrow at my end with those versions and check if I face this issue as well. Also, do you happen to have a debug verbosity log from Arnold that you could share here?
Brian Meanley
Sep 20, 2018, 9:18:36 PM9/20/18
to gaffe...@googlegroups.com
I can help with some of that:
OS: centos 6.5, and centos7 (seeing the crashes on both)
Maya: 2018.2
Maya: 2018.2
MtoA: 3.0.1.1
Arnold Core: 5.1.1.1
Gaffer: 0.46.0.0
I'm not at my desk right at the moment though, I'll try to follow up tomorrow with some more detailed debug logs if I can.
Thanks for taking a look!
-Brian
Sachin Shrestha
Sep 20, 2018, 9:30:05 PM9/20/18
to gaffe...@googlegroups.com
Thanks for the info, I’ll try to repro this today. But I just remembered something. For xgen procedural, we were seeing the same crash at our end when using the External Procedural node in gaffer by passing it all the procedural parameters. Wrapping that into an .ass file instead was working without any issues. So in my tests what I concluded was it was due to instancing of the procedural in gaffer. Since everything gets instanced by gaffer when exporting the scene, even the xgen_procedural gets instanced and that causes Arnold to crash which causes gaffer to crash. This doesn’t happen if you use a .ass file as that’s a regular Arnold procedural node which seems to support instancing. I was able to confirm this in Maya/MtoA as well as kick renders on the command-line and even with just hand writing a .ass file with an instance of a xgen_procedural node. We have another custom hair procedural that we use internally that worked perfectly fine within gaffer with the external procedural node so I guess the procedurals are written in a way that are causing some memory access issue due to which Arnold crashes and that takes gaffer down with it.
I’ll double check this at my end today with the bifrost procedural but I have a strong hunch this could be a reason. We may need to write to SolidAngle/Autodesk in that case. I had it in my to-do for the xgen_procedrual but if this proves right then this would be another one.
Brian Meanley
Sep 20, 2018, 9:46:21 PM9/20/18
to gaffe...@googlegroups.com
That sounds like it could indeed be related to what I am seeing here. The one oddity right now on our end though seems to be that even when the procedural is wrapped up inside of an ass file, it still causes crashes on our render farm. Though, since I am able to complete a render, and get a valid frame out when I do it locally, this might very well be a different issue altogether....
Of interest, just out of curiosity, I just switched the "bifrost_volume" name of the external procedural, to "bifrost_points", and set the step-size to 0, and my IPR render no longer crashed. Haven't confirmed anything on the farm yet, but will continue to look into things in the morning.
Thanks again!
-Brian
John Haddon
Sep 21, 2018, 6:05:19 AM9/21/18
to gaffe...@googlegroups.com
Have you tried writing an ass file with an ArnoldRender node, and then rendering it manually from the command line with `kick`? It's possible there's a library conflict between Gaffer and the bifrost procedural, and by rendering outside of Gaffer you should be able to eliminate that.
Cheers...
John
To unsubscribe from this group and stop receiving emails from it, send an email to gaffer-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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+unsubscribe@googlegroups.com.
Sachin Shrestha
Sep 21, 2018, 10:27:18 AM9/21/18
to gaffer-dev
It seems to crash gaffer at my end too. I tried exporting an ass file using the ArnoldRender node and that also crashed the export (gaffer session was intact though) with the below traceback:
I tried this with the same app versions as Brian with the only difference being the Maya version which was 2018.4. The OS is CentOS 7.5.x.
Additionally, I exported a scene ass file from MtoA and manually ginstanced the bifrost node to match what gaffer would have exported if it hadn't crashed. That rendered fine with kick on the command line so perhaps my earlier assumption of bifrost procedural instancing issue can be ruled out (that's still a problem with xgen though but its unrelated to this topic). So it could indeed be some library version clash issue. I have attached a simple repro if it helps.
00:00:00 229MB ERROR | signal caught: SIGSEGV -- Invalid memory reference
****
* Arnold 5.1.1.1 [3849b993] linux clang-5.0.0 oiio-1.7.17 osl-1.9.0 vdb-4.0.0 clm-1.0.3.513 rlm-12.2.2 2018/06/26 20:42:28
* CRASHED in __strlen_sse2_pminub at 00:00:00
* signal caught: SIGSEGV -- Invalid memory reference (address not mapped to object)
*
* backtrace:
* 0 0x00007f60ba86d2a2 [libai.so ]
* 1 0x00007f60de4816cf [libpthread.so.0 ] _L_unlock_13 [funlockfile.c : ?]
>> 2 0x00007f60ddb0aff0 [libc.so.6 ] __strlen_sse2_pminub [ : ?]
* 3 0x00007f60ddb0aff0 [libc.so.6 ] [ : ?]
* 4 0x00007f60b9d69feb [libIECoreArnold.so] IECoreArnold::ParameterAlgo::dataToArray(IECore::Data const*, int)
* 5 0x00007f60b9d6b5d9 [libIECoreArnold.so] [ParameterAlgo.cpp : ?]
* 6 0x00007f60b9d6d677 [libIECoreArnold.so] IECoreArnold::ParameterAlgo::setParameter(AtNode*, AtParamEntry const*, IECore::Data const*)
* 7 0x00007f60b9d6d6d0 [libIECoreArnold.so] IECoreArnold::ParameterAlgo::setParameter(AtNode*, AtString, IECore::Data const*)
* 8 0x00007f60b9d6dba1 [libIECoreArnold.so] IECoreArnold::ParameterAlgo::setParameter(AtNode*, char const*, IECore::Data const*)
* 9 0x00007f60b9d6dbda [libIECoreArnold.so] IECoreArnold::ParameterAlgo::setParameters(AtNode*, std::map<IECore::InternedString, boost::intrusive_ptr<IECore::Data>, std::less<IECore::InternedString>, std::allocator<std::pair<IECore::InternedString const, boost::intrusive_ptr<IECore::Data> > > > const&)
* 10 0x00007f60bdc16b10 [libGafferArnold.so] IECoreArnoldPreview::ProceduralAlgo::convert(IECoreScene::ExternalProcedural const*, std::string const&, AtNode const*) [ : ?]
* 11 0x00007f60bdc1d1dd [libGafferArnold.so] [Renderer.cpp : ?]
* 12 0x00007f60bdc1e293 [libGafferArnold.so] (anonymous namespace) [Renderer.cpp : ?]
* 13 0x00007f60bdc1e47a [libGafferArnold.so] [Renderer.cpp : ?]
* 14 0x00007f60c677f95c [libGafferScene.so ] GafferScene::Detail::LocationTask<(anonymous namespace) [RendererAlgo.cpp : ?]
* 15 0x00007f60d1d517b2 [libtbb.so.2 ] tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::local_wait_for_all(tbb::task&, tbb::task*) [custom_scheduler.h:501]
* 16 0x00007f60d1d4a861 [libtbb.so.2 ] [arena.cpp :159]
* 17 0x00007f60d1d4934a [libtbb.so.2 ] tbb::internal::arena::process(tbb::internal::generic_scheduler&) [market.cpp :697]
* 18 0x00007f60d1d45625 [libtbb.so.2 ] [private_server.cpp:271]
* 19 0x00007f60d1d45858 [libtbb.so.2 ] tbb::internal::market::process(rml::job&) [private_server.cpp:224]
* 20 0x00007f60de479e24 [libpthread.so.0 ] [pthread_create.c : ?]
* 21 0x00007f60dda9abac [libc.so.6 ] clone
*
* loaded modules:
* 0x00007f60b9f81000 libai.so
* 0x00007f60de472000 libpthread.so.0
* 0x00007f60dd99c000 libc.so.6
* 0x00007f60b9d4d000 libIECoreArnold.so
* 0x00007f60bdbbb000 libGafferArnold.so
* 0x00007f60c665e000 libGafferScene.so
* 0x00007f60d1d21000 libtbb.so.2
*
* memory: VM 94911 MB, RSS 230 MB, 1 page faults
****
I tried this with the same app versions as Brian with the only difference being the Maya version which was 2018.4. The OS is CentOS 7.5.x.
Interactive render crashes with a different backtrace though:
00:09:10 412MB ERROR | signal caught: SIGSEGV -- Invalid memory reference
****
* Arnold 5.1.1.1 [3849b993] linux clang-5.0.0 oiio-1.7.17 osl-1.9.0 vdb-4.0.0 clm-1.0.3.513 rlm-12.2.2 2018/06/26 20:42:28
* CRASHED in IECoreArnold::ParameterAlgo::dataToArray at 00:00:00
* signal caught: SIGSEGV -- Invalid memory reference (address not mapped to object)
*
* backtrace:
* 0 0x00007f44d9d772a2 [libai.so ]
* 1 0x00007f450a8b76cf [libpthread.so.0 ] _L_unlock_13 [funlockfile.c : ?]
>> 2 0x00007f44de7f6fe2 [libIECoreArnold.so ] IECoreArnold::ParameterAlgo::dataToArray(IECore::Data const*, int)
* 3 0x00007f44de7f6fe2 [libIECoreArnold.so ] IECoreArnold::ParameterAlgo::dataToArray(IECore::Data const*, int)
* 4 0x00007f44de7fa677 [libIECoreArnold.so ] IECoreArnold::ParameterAlgo::setParameter(AtNode*, AtParamEntry const*, IECore::Data const*)
* 5 0x00007f44de7fa6d0 [libIECoreArnold.so ] IECoreArnold::ParameterAlgo::setParameter(AtNode*, AtString, IECore::Data const*)
* 6 0x00007f44de7faba1 [libIECoreArnold.so ] IECoreArnold::ParameterAlgo::setParameter(AtNode*, char const*, IECore::Data const*)
* 7 0x00007f44de7fabda [libIECoreArnold.so ] IECoreArnold::ParameterAlgo::setParameters(AtNode*, std::map<IECore::InternedString, boost::intrusive_ptr<IECore::Data>, std::less<IECore::InternedString>, std::allocator<std::pair<IECore::InternedString const, boost::intrusive_ptr<IECore::Data> > > > const&)
* 8 0x00007f44e33b7b10 [libGafferArnold.so ] IECoreArnoldPreview::ProceduralAlgo::convert(IECoreScene::ExternalProcedural const*, std::string const&, AtNode const*) [ : ?]
* 9 0x00007f44e33be1dd [libGafferArnold.so ] [Renderer.cpp : ?]
* 10 0x00007f44e33bf293 [libGafferArnold.so ] (anonymous namespace) [Renderer.cpp : ?]
* 11 0x00007f44e33bf47a [libGafferArnold.so ] [Renderer.cpp : ?]
* 12 0x00007f44e6503400 [libGafferScene.so ] GafferScene::InteractiveRender::SceneGraph::updateObject(Gaffer::TypedObjectPlug<IECore::Object> const*, GafferScene::InteractiveRender::SceneGraph::Type, IECoreScenePreview::Renderer*, IECore::CompoundObject const*)
* 13 0x00007f44e6503c31 [libGafferScene.so ] GafferScene::InteractiveRender::SceneGraph::update(GafferScene::ScenePlug const*, std::vector<IECore::InternedString, std::allocator<IECore::InternedString> > const&, unsigned int, unsigned int, GafferScene::InteractiveRender::SceneGraph::Type, IECoreScenePreview::Renderer*, IECore::CompoundObject const*, GafferScene::RendererAlgo::RenderSets const&)
* 14 0x00007f44e65041f6 [libGafferScene.so ] GafferScene::InteractiveRender::SceneGraphUpdateTask::execute()
* 15 0x00007f44fe1877b2 [libtbb.so.2 ] tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::local_wait_for_all(tbb::task&, tbb::task*) [custom_scheduler.h : 501]
* 16 0x00007f44e6504448 [libGafferScene.so ] GafferScene::InteractiveRender::SceneGraphUpdateTask::execute()
* 17 0x00007f44fe1877b2 [libtbb.so.2 ] [custom_scheduler.h : 501]
* 18 0x00007f44e6504448 [libGafferScene.so ] GafferScene::InteractiveRender::SceneGraphUpdateTask::execute()
* 19 0x00007f44fe1877b2 [libtbb.so.2 ] tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::local_wait_for_all(tbb::task&, tbb::task*) [custom_scheduler.h : 501]
* 20 0x00007f44fe18459f [libtbb.so.2 ] [scheduler.cpp : 677]
* 21 0x00007f44e6501133 [libGafferScene.so ] GafferScene::InteractiveRender::update()
* 22 0x00007f44e6501a87 [libGafferScene.so ] GafferScene::InteractiveRender::plugDirtied(Gaffer::Plug const*)
* 23 0x00007f44f89f68a9 [libGaffer.so ] boost::signal1<void, Gaffer::Plug*, boost::last_value<void>, int, std::less<int>, boost::function<void (Gaffer::Plug*) [ : ?]
* 24 0x00007f44f89f7960 [libGaffer.so ] Gaffer::Plug::DirtyPlugs::emit()
* 25 0x00007f44f89ef80d [libGaffer.so ] Gaffer::Plug::propagateDirtiness(Gaffer::Plug*)
* 26 0x00007f44f8a35685 [libGaffer.so ] Gaffer::ValuePlug::SetValueAction::doAction()
* 27 0x00007f44f8a08d54 [libGaffer.so ] Gaffer::ScriptNode::addAction(boost::intrusive_ptr<Gaffer::Action>)
* 28 0x00007f44f89631c2 [libGaffer.so ] Gaffer::Action::enact(boost::intrusive_ptr<Gaffer::Action>)
* 29 0x00007f44f8a30d4c [libGaffer.so ] Gaffer::ValuePlug::setObjectValue(boost::intrusive_ptr<IECore::Object const>)
* 30 0x00007f44f89e79ca [libGaffer.so ] Gaffer::NumericPlug<int>::setValue(int)
* 31 0x00007f44f9086af3 [_Gaffer.so ] void (anonymous namespace) [NumericPlugBinding.cpp : ?]
* 32 0x00007f44f908cc0d [_Gaffer.so ] [ : ?]
* 33 0x00007f45006d1f6c [libboost_python.so.1.61.0] boost::python::objects::function::call(_object*, _object*)
* 34 0x00007f45006d2177 [libboost_python.so.1.61.0] [function.cpp : ?]
* 35 0x00007f45006d8a5a [libboost_python.so.1.61.0] boost::python::detail::exception_handler::operator()
* 36 0x00007f44e018f762 [pyopenvdb.so ] boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<openvdb::v4_0_2::ValueError, void (*)
* 37 0x00007f45006d8a39 [libboost_python.so.1.61.0] boost::python::detail::exception_handler::operator()
* 38 0x00007f44e018f6a2 [pyopenvdb.so ] boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<openvdb::v4_0_2::TypeError, void (*)
* 39 0x00007f45006d8a39 [libboost_python.so.1.61.0] boost::python::detail::exception_handler::operator()
* 40 0x00007f44e018f5e2 [pyopenvdb.so ] boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<openvdb::v4_0_2::RuntimeError, void (*)
* 41 0x00007f45006d8a39 [libboost_python.so.1.61.0] boost::python::detail::exception_handler::operator()
* 42 0x00007f44e018f522 [pyopenvdb.so ] boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<openvdb::v4_0_2::ReferenceError, void (*)
* 43 0x00007f45006d8a39 [libboost_python.so.1.61.0] boost::python::detail::exception_handler::operator()
* 44 0x00007f44e018f462 [pyopenvdb.so ] boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<openvdb::v4_0_2::NotImplementedError, void (*)
* 45 0x00007f45006d8a39 [libboost_python.so.1.61.0] boost::python::detail::exception_handler::operator()
* 46 0x00007f44e018f3a2 [pyopenvdb.so ] boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<openvdb::v4_0_2::LookupError, void (*)
* 47 0x00007f45006d8a39 [libboost_python.so.1.61.0] boost::python::detail::exception_handler::operator()
* 48 0x00007f44e018f2e2 [pyopenvdb.so ] boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<openvdb::v4_0_2::KeyError, void (*)
* 49 0x00007f45006d8a39 [libboost_python.so.1.61.0] boost::python::detail::exception_handler::operator()
* 50 0x00007f44e018f222 [pyopenvdb.so ] boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<openvdb::v4_0_2::IoError, void (*)
* 51 0x00007f45006d8a39 [libboost_python.so.1.61.0] boost::python::detail::exception_handler::operator()
* 52 0x00007f44e018f162 [pyopenvdb.so ] boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<openvdb::v4_0_2::IndexError, void (*)
* 53 0x00007f45006d8a39 [libboost_python.so.1.61.0] boost::python::detail::exception_handler::operator()
* 54 0x00007f44e018f0a2 [pyopenvdb.so ] boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<openvdb::v4_0_2::IllegalValueException, void (*)
* 55 0x00007f45006d8a39 [libboost_python.so.1.61.0] boost::python::detail::exception_handler::operator()
* 56 0x00007f44e018efe2 [pyopenvdb.so ] boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<openvdb::v4_0_2::ArithmeticError, void (*)
* 57 0x00007f45006d8a39 [libboost_python.so.1.61.0] boost::python::detail::exception_handler::operator()
* 58 0x00007f44fcb40eb0 [libIECorePython.so ] boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<IECore::Cancelled, IECorePython::bindCanceller() [CancellerBinding.cpp : ?]
* 59 0x00007f45006d8a39 [libboost_python.so.1.61.0] boost::python::detail::exception_handler::operator()
* 60 0x00007f44fcbb2d52 [libIECorePython.so ] [ : ?]
* 61 0x00007f45006d8a39 [libboost_python.so.1.61.0] boost::python::detail::exception_handler::operator()
* 62 0x00007f44ffc1b6c2 [iexmodule.so ] boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<Iex_2_2::BaseExc, void (*) [translate_exception.hpp: 48]
* 63 0x00007f45006d882e [libboost_python.so.1.61.0] boost::python::handle_exception_impl(boost::function0<void>)
* 64 0x00007f45006cf558 [libboost_python.so.1.61.0] [function.cpp : ?]
* 65 0x00007f450ab18a32 [libpython2.7.so.1.0 ] PyObject_Call [abstract.c :2547]
* 66 0x00007f450abcf1be [libpython2.7.so.1.0 ] PyEval_EvalFrameEx [ceval.c :4569]
* 67 0x00007f450abd3a8b [libpython2.7.so.1.0 ] PyEval_EvalCodeEx [ceval.c :3584]
* 68 0x00007f450ab49c1c [libpython2.7.so.1.0 ] call_function [funcobject.c : 523]
* 69 0x00007f450ab18a32 [libpython2.7.so.1.0 ] PyObject_Call [abstract.c :2547]
* 70 0x00007f450abcc726 [libpython2.7.so.1.0 ] PyEval_EvalFrameEx [ceval.c :4666]
* 71 0x00007f450abd3a8b [libpython2.7.so.1.0 ] PyEval_EvalCodeEx [ceval.c :3584]
* 72 0x00007f450ab49b4b [libpython2.7.so.1.0 ] [funcobject.c : 523]
* 73 0x00007f450ab18a32 [libpython2.7.so.1.0 ] PyObject_Call [abstract.c :2547]
* 74 0x00007f450ab29e0b [libpython2.7.so.1.0 ] [classobject.c :2602]
* 75 0x00007f450ab18a32 [libpython2.7.so.1.0 ] PyObject_Call [abstract.c :2547]
* 76 0x00007f450ab87ef9 [libpython2.7.so.1.0 ] [typeobject.c :5546]
* 77 0x00007f450ab18a32 [libpython2.7.so.1.0 ] PyObject_Call [abstract.c :2547]
* 78 0x00007f450abc9726 [libpython2.7.so.1.0 ] PyEval_CallObjectWithKeywords [ceval.c :4221]
* 79 0x00007f450abf4526 [libpython2.7.so.1.0 ] PyEval_CallFunction [modsupport.c : 583]
* 80 0x00007f44f714ed57 [_GafferUI.so ] boost::detail::function::function_obj_invoker1<GafferBindings::Detail::Slot<boost::signal<bool (boost::python::api::object) [ : ?]
* 81 0x00007f44f71529b2 [_GafferUI.so ] [ : ?]
* 82 0x00007f44f7152f11 [_GafferUI.so ] boost::signal1<bool, boost::python::api::object, GafferUI::EventSignalCombiner<bool>, int, std::less<int>, boost::function<bool (boost::python::api::object) [ : ?]
* 83 0x00007f44f714e6eb [_GafferUI.so ] [ : ?]
* 84 0x00007f45006d1f6c [libboost_python.so.1.61.0] boost::python::objects::function::call(_object*, _object*)
* 85 0x00007f45006d2177 [libboost_python.so.1.61.0] [function.cpp : ?]
* 86 0x00007f45006d8a5a [libboost_python.so.1.61.0] boost::python::detail::exception_handler::operator()
* 87 0x00007f44e018f762 [pyopenvdb.so ] boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<openvdb::v4_0_2::ValueError, void (*)
* 88 0x00007f45006d8a39 [libboost_python.so.1.61.0] boost::python::detail::exception_handler::operator()
* 89 0x00007f44e018f6a2 [pyopenvdb.so ] boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<openvdb::v4_0_2::TypeError, void (*)
* 90 0x00007f45006d8a39 [libboost_python.so.1.61.0] boost::python::detail::exception_handler::operator()
* 91 0x00007f44e018f5e2 [pyopenvdb.so ] boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<openvdb::v4_0_2::RuntimeError, void (*)
* 92 0x00007f45006d8a39 [libboost_python.so.1.61.0] boost::python::detail::exception_handler::operator()
* 93 0x00007f44e018f522 [pyopenvdb.so ] boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<openvdb::v4_0_2::ReferenceError, void (*)
* 94 0x00007f45006d8a39 [libboost_python.so.1.61.0] boost::python::detail::exception_handler::operator()
* 95 0x00007f44e018f462 [pyopenvdb.so ] boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<openvdb::v4_0_2::NotImplementedError, void (*)
* 96 0x00007f45006d8a39 [libboost_python.so.1.61.0] boost::python::detail::exception_handler::operator()
* 97 0x00007f44e018f3a2 [pyopenvdb.so ] boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<openvdb::v4_0_2::LookupError, void (*)
* 98 0x00007f45006d8a39 [libboost_python.so.1.61.0] boost::python::detail::exception_handler::operator()
* 99 0x00007f44e018f2e2 [pyopenvdb.so ] boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<openvdb::v4_0_2::KeyError, void (*)
*
* loaded modules:
* 0x00007f44d948b000 libai.so
* 0x00007f450a8a8000 libpthread.so.0
* 0x00007f44de7da000 libIECoreArnold.so
* 0x00007f44e335c000 libGafferArnold.so
* 0x00007f44e641b000 libGafferScene.so
* 0x00007f44fe157000 libtbb.so.2
* 0x00007f44f88f4000 libGaffer.so
* 0x00007f44f8ea7000 _Gaffer.so
* 0x00007f450069f000 libboost_python.so.1.61.0
* 0x00007f44dfcf3000 pyopenvdb.so
* 0x00007f44fc908000 libIECorePython.so
* 0x00007f44ffb81000 iexmodule.so
* 0x00007f450aac4000 libpython2.7.so.1.0
* 0x00007f44f6fe0000 _GafferUI.so
*
* memory: VM 66340 MB, RSS 412 MB, 2 page faults
****
Additionally, I exported a scene ass file from MtoA and manually ginstanced the bifrost node to match what gaffer would have exported if it hadn't crashed. That rendered fine with kick on the command line so perhaps my earlier assumption of bifrost procedural instancing issue can be ruled out (that's still a problem with xgen though but its unrelated to this topic). So it could indeed be some library version clash issue. I have attached a simple repro if it helps.
Cheers,
Sachin
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.
--
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.
--
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.
--
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.
--
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.
--
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.
John Haddon
Sep 21, 2018, 10:33:29 AM9/21/18
to gaffe...@googlegroups.com
Hi Sachin,
Could one of you send me the ExternalProcedural node corresponding to your crash? The stack trace implies it's something in Cortex rather than an Arnold problem, so I'd like to take a look. This wouldn't account for Brian's crashes when the procedural is in an ass file though, so we may have two separate issues here...
Cheers...
John
To unsubscribe from this group and stop receiving emails from it, send an email to gaffer-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
John Haddon - R&D Programmer
Image Engine
15 West 5th Avenue, Vancouver, BC, V5Y 1H4, Canada
If you are not the intended recipient, disclosure, copying, distribution and use of this email is prohibited. Please notify us immediately and delete this email from your systems. You may contact us at in...@image-engine.com if you do not wish to receive further commercial electronic messages. We may still send you messages for which we do not require consent.
Brian Meanley
Sep 21, 2018, 1:11:05 PM9/21/18
to gaffe...@googlegroups.com
A couple of other scenarios...
Ass file exported from Gaffer using an external_procedural node to hold the bifrost procedrual, rendered external to Gaffer using Kick:
- With progressive rendering: crashes at the end of the first progressive pass (see log below)
- With progressive rendering disabled (-dp): renders fine, and outputs an exr file.
Log from progressive render using kick:
****
* Arnold 5.1.1.1 [3849b993] linux clang-5.0.0 oiio-1.7.17 osl-1.9.0 vdb-4.0.0 clm-1.0.3.513 rlm-12.2.2 2018/06/26 20:42:28
* CRASHED in libai.so (0x00007fa555865653) at 00:00:00, pixel (952, 440)
* signal caught: SIGSEGV -- Invalid memory reference (address not mapped to object)
*
* backtrace:
* 0 0x00007fa55591e2a2 [libai.so ]
* 1 0x00000034e1a3299f [libc.so.6 ]
>> 2 0x00007fa555865653 [libai.so ]
* 3 0x00007fa555865653 [libai.so ]
* 4 0x00007fa5559a7e8d [libai.so ]
* 5 0x00007fa5552c24e8 [libai.so ]
* 6 0x00007fa555875f9a [libai.so ]
* 7 0x00007fa55586770a [libai.so ]
* 8 0x00007fa555873e0b [libai.so ]
* 9 0x00007fa5559217cd [libai.so ]
* 10 0x00000034e1e079d0 [libpthread.so.0] [pthread_create.c:0]
* 11 0x00000034e1ae8b6c [libc.so.6 ] clone
*
* loaded modules:
* 0x00007fa555032000 libai.so
* 0x00000034e1a00000 libc.so.6
* 0x00000034e1e00000 libpthread.so.0
*
* memory: VM 1119 MB, RSS 338 MB, 1 page faults
****
Brian Meanley
Sep 21, 2018, 1:40:31 PM9/21/18
to gaffe...@googlegroups.com
Amending my previous post....
Ass file exported from Gaffer using an external_procedural node to hold the bifrost procedrual, rendered external to Gaffer using Kick:
- With progressive rendering: crashes at the end of the first progressive pass.
- With progressive rendering disabled (-dp): renders fine, and outputs an exr file.
Ass file exported from Gaffer using an external_procedural node to hold the bifrost procedrual; however, the instance generated by gaffer has been removed, and the visibility of the primary procedural has been returned to 255. Rendered external to Gaffer using Kick:
- With progressive rendering: renders fine, and outputs a valid exr file.- Without progressive rendering: renders fine, and outputs a valid exr file.
- With IPR: crashes at the end of the first progressive pass.
It seems that both internal, and external to Gaffer, the results are the same. The creation of the instance, seems to cause issues with the IPR renders (which is presumably why I don't have the same issues with the Ass-file version). However, this does not yet explain to my why I am seeing different results on our render-farm, so I will have to continue to dig into that to see if I can find some out-lying issue.- With an arnold render node executed though the local dispatcher: Renders, and outputs a valid exr file.
Thanks again for everyone for digging into this!
-Brian
Brian Meanley
Sep 21, 2018, 2:31:59 PM9/21/18
to gaffe...@googlegroups.com
A bit more....
Rendered locally in Gaffer using an external_procedural node to hold the bifrost procedrual:- With IPR: crashes at the end of the first progressive pass.- With an arnold render node executed though the local dispatcher: Renders, and outputs a valid exr file.
This same script file, when rendered with the gaffer execute command, crashes at the end of the render. This would seemingly be the same result that I am seeing when I submit the script to our render-farm. See the log below:
-Brian00:00:01 514MB WARNING | [BIFROST] Don't know how to export channel 'vorticity'. Available channels are: ' densitysmokesmoke_distancetemperaturetransitionvelocity_uvelocity_vvelocity_w'00:00:01 514MB | [volume] instance:fae2383c17d922bcd8da55b74722b792: auto bounds from volume plugin: [ -1.760000 -0.385000 -2.310000 ] -> [ 2.090000 12.265000 2.090000 ]00:00:01 514MB | [volume] instance:fae2383c17d922bcd8da55b74722b792: using volume plugin reported step size of 0.02750000:00:02 645MB | 0% done - 42 rays/pixel00:00:15 649MB | 5% done - 56 rays/pixel00:00:18 650MB | 10% done - 44 rays/pixel00:00:31 651MB | 15% done - 62 rays/pixel00:00:33 652MB | 20% done - 42 rays/pixel00:00:35 652MB | 25% done - 42 rays/pixel00:00:36 652MB | 30% done - 41 rays/pixel00:00:38 652MB | 35% done - 41 rays/pixel00:00:39 652MB | 40% done - 39 rays/pixel00:00:40 652MB | 45% done - 39 rays/pixel00:00:41 653MB | 50% done - 39 rays/pixel00:00:42 653MB | 55% done - 38 rays/pixel00:00:43 653MB | 60% done - 38 rays/pixel00:00:43 653MB | 65% done - 38 rays/pixel00:00:44 653MB | 70% done - 38 rays/pixel00:00:44 653MB | 75% done - 38 rays/pixel00:00:45 653MB | 80% done - 38 rays/pixel00:00:45 653MB | 85% done - 38 rays/pixel00:00:46 653MB | 90% done - 38 rays/pixel00:00:46 653MB | 95% done - 38 rays/pixel00:00:52 655MB | 100% done - 75 rays/pixel/mnt/warehouse6/cask3/tools/scripts/sh/wtGaffer.sh: line 269: 2054 Segmentation fault (core dumped) ${WT_GAFFER_ROOT}/bin/gaffer ${WT_GAFFERARGS}
Brian Meanley
Sep 25, 2018, 12:35:28 PM9/25/18
to gaffe...@googlegroups.com
Just a quick follow-up on this.
I've reached out to Solidangle with some repo scenes, and they can confirm the crashes that I am seeing here. They have created a dev ticket for it, so hopefully something can be sorted out sooner rather than later. The bug that I submitted was specifically related to instanced "bifrost_volume" procedurals, and only when progressive rendering is enabled. When using other bifrost nodes (i.e. "bifrost_points"), or when disabling IPR renders, I was not able to reproduce the same crash.
I'll follow up with any further information that I come across.
-Brian
Sachin Shrestha
Sep 27, 2018, 1:16:40 AM9/27/18
to gaffe...@googlegroups.com
Thanks for the update Brian. This reminds me I should also post the similar issue with the xgen_procedural (which is forcing us to wrap it in an ass file for now in gaffer).
--
John Haddon
Sep 27, 2018, 4:00:00 AM9/27/18
to gaffe...@googlegroups.com
If this is becoming a big deal, there is also the option of adjusting Gaffer's output so we don't instance ExternalProcedurals. We already have a special case for ass files, so it wouldn't be hard to add more special cases. If you guys want to take a look at that and need any pointers, just let us know...
Cheers...
John
To unsubscribe from this group and stop receiving emails from it, send an email to gaffer-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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+unsubscribe@googlegroups.com.
Sachin Shrestha
Sep 27, 2018, 12:37:33 PM9/27/18
to gaffe...@googlegroups.com
That sounds interesting John. Could you please show us how? I might experiment with it so that we ca directly use the xgen procedural via an ExternalProcedural node.
Cheers,
Sachin
Cheers,
Sachin
On Thu, 27 Sep 2018 at 13:30, John Haddon <jo...@image-engine.com> wrote:
If this is becoming a big deal, there is also the option of adjusting Gaffer's output so we don't instance ExternalProcedurals. We already have a special case for ass files, so it wouldn't be hard to add more special cases. If you guys want to take a look at that and need any pointers, just let us know...Cheers...John
On 27 September 2018 at 06:16, Sachin Shrestha <noizf...@gmail.com> wrote:
Thanks for the update Brian. This reminds me I should also post the similar issue with the xgen_procedural (which is forcing us to wrap it in an ass file for now in gaffer).
On Tue, 25 Sep 2018 at 22:05, Brian Meanley <brian....@gmail.com> wrote:
Just a quick follow-up on this.I've reached out to Solidangle with some repo scenes, and they can confirm the crashes that I am seeing here. They have created a dev ticket for it, so hopefully something can be sorted out sooner rather than later. The bug that I submitted was specifically related to instanced "bifrost_volume" procedurals, and only when progressive rendering is enabled. When using other bifrost nodes (i.e. "bifrost_points"), or when disabling IPR renders, I was not able to reproduce the same crash.I'll follow up with any further information that I come across.---Brian
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.
--
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.
--studio: +1 (604) 874-5634 | jo...@image-engine.com | www.image-engine.comJohn Haddon - R&D ProgrammerImage Engine
15 West 5th Avenue, Vancouver, BC, V5Y 1H4, Canada
If you are not the intended recipient, disclosure, copying, distribution and use of this email is prohibited. Please notify us immediately and delete this email from your systems. You may contact us at in...@image-engine.com if you do not wish to receive further commercial electronic messages. We may still send you messages for which we do not require consent.
--
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.
John Haddon
Sep 27, 2018, 3:52:27 PM9/27/18
to gaffe...@googlegroups.com
This is the spot where we decide whether or not to instance an object :
You could add a cast to see if the object is an ExternalProcedural, and return false if it.
Cheers...
John
On 27 September 2018 at 17:37, Sachin Shrestha <noizf...@gmail.com> wrote:
That sounds interesting John. Could you please show us how? I might experiment with it so that we ca directly use the xgen procedural via an ExternalProcedural node.
Cheers,
Sachin
On Thu, 27 Sep 2018 at 13:30, John Haddon <jo...@image-engine.com> wrote:
If this is becoming a big deal, there is also the option of adjusting Gaffer's output so we don't instance ExternalProcedurals. We already have a special case for ass files, so it wouldn't be hard to add more special cases. If you guys want to take a look at that and need any pointers, just let us know...Cheers...John
On 27 September 2018 at 06:16, Sachin Shrestha <noizf...@gmail.com> wrote:
Thanks for the update Brian. This reminds me I should also post the similar issue with the xgen_procedural (which is forcing us to wrap it in an ass file for now in gaffer).
On Tue, 25 Sep 2018 at 22:05, Brian Meanley <brian....@gmail.com> wrote:
Just a quick follow-up on this.I've reached out to Solidangle with some repo scenes, and they can confirm the crashes that I am seeing here. They have created a dev ticket for it, so hopefully something can be sorted out sooner rather than later. The bug that I submitted was specifically related to instanced "bifrost_volume" procedurals, and only when progressive rendering is enabled. When using other bifrost nodes (i.e. "bifrost_points"), or when disabling IPR renders, I was not able to reproduce the same crash.I'll follow up with any further information that I come across.---Brian
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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+unsubscribe@googlegroups.com.
--studio: +1 (604) 874-5634 | jo...@image-engine.com | www.image-engine.comJohn Haddon - R&D ProgrammerImage Engine
15 West 5th Avenue, Vancouver, BC, V5Y 1H4, Canada
If you are not the intended recipient, disclosure, copying, distribution and use of this email is prohibited. Please notify us immediately and delete this email from your systems. You may contact us at in...@image-engine.com if you do not wish to receive further commercial electronic messages. We may still send you messages for which we do not require consent.
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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+unsubscribe@googlegroups.com.
Sachin Shrestha
Sep 29, 2018, 4:38:11 AM9/29/18
to gaffer-dev
Thanks for the pointers John.
Investigating this a bit further on the xgen_procedural side, the last issue that we had discovered was that the crash did not occur for us neither during IPR nor arnold render session. The problem was it didn't render the xgen at all although the logs seemed to point to the xgen procedural actually getting expanded at render time. I figured out this was due to the procedural's visibility being set to 0 (since the ginstance is set to 255). It seems like an issue on the arnold side (attached an ass file for anyone who wanted to investigate). I'm reporting this to the Arnold folks since this does not really seem to be an issue with gaffer (and we would also lose the procedural instancing features like you mentioned).
Cheers,
Sachin
Reply all
Reply to author
Forward
0 new messages