Ah you’re right!
But what about inline vex?
Found 115 posts.
Search results Show results as topic list.
Technical Discussion » read detail attribute in Shading context
- tmdag
- 168 posts
- Offline
Technical Discussion » read detail attribute in Shading context
- tmdag
- 168 posts
- Offline
Hi!
Is there a way to read detail attribute within a shading context of the object we are currently rendering ?
Or in other words - how can i access inline geoself() in shader ?
Is there a way to read detail attribute within a shading context of the object we are currently rendering ?
Or in other words - how can i access inline geoself() in shader ?
Solaris and Karma » AOV per each light
- tmdag
- 168 posts
- Offline
Thanks, this is what we are doing at this moment, but with lots of lights, it is a lot of manual work
Solaris and Karma » AOV per each light
- tmdag
- 168 posts
- Offline
In mantra we could "export variable for each light" with 'all' vex variable, which would automatically create AOVs per each light.
How can we do so using Karma ? (having 100 lights in the scene, would rather avoid setting each one of them manually)
How can we do so using Karma ? (having 100 lights in the scene, would rather avoid setting each one of them manually)
Edited by tmdag - Jan. 4, 2021 21:20:46
Solaris and Karma » transparency shadows
- tmdag
- 168 posts
- Offline
jsmack
The only way in Karma is with faked caustics. Maybe Sidefx will add a bidirectional pathtracing mode, but as most renderers don't implement bidirectional pathtracing or another intelligent way to resolve caustic paths. Considering the complexity and expense of cutting edge light transport research, I wouldn't hold my breath. I don't think photons are coming back, they're an antiquated way of approaching caustics that have many problems as you found. At the very least, they might bring back ‘all paths’ mode, but it's pretty poor at resolving caustic paths from small sources.
“caustic light” in mantra is a bidirectional path tracing mode, but doesn't look like it's performing as expected anymore.
Therefore that is my global question to SideFX here - especially if we want to start considering Karma as our future, production ready renderer.
Solaris and Karma » transparency shadows
- tmdag
- 168 posts
- Offline
jsmackI'm aware that outside prevew we won't get buckets, but it's good that it's a _known_ issue then. Do you happen to know RFA confining that Sesi is aware? Thanks!
The bucket artifacts are a known issue when using preview mode with mantra. Render to mplay, or disable preview mode to make them go away.
Not sure why you're getting those fireflies in karma. I'm not seeing that.
As for Karma fireflies - this is also IP, just tried cranking up Pixel Samples to 512, reduced Color Limit to 1 (just in case). Got rid of SOME of them (they are still there, just suppressed)
I've tried nonIP version, I'm still trying to get my head around with Solaris - couldn't find diffuse/reflection/refraction bounce limits on Karma/rendersettings node that are available under display setting. Is it something we have to add manually ? (need to read more documentation here)
Outside render artifacts issues, my main question is:
As for today - in order to get a “proper” transparent shadows - the only way for us is to use a principled shader with faked caustics option ? (of course we probably could add same functionality to the classic mantra shader, which is just manipulating opacity of the object as I understand it correctly)
Now, if that is just a cheat - which probably will work in most cases - do we get any possibility of doing it little bit more “properly” Like with ‘caustic’ light in the past - which for some reason I couldn't get to work in this example?
Edited by tmdag - Oct. 17, 2020 17:02:45
Solaris and Karma » transparency shadows
- tmdag
- 168 posts
- Offline
You have very fair point with the normals! Thanks for pointing that out.
Like I was mentioning - I know it's not an easy subject for a renderer(s) but want to explore all options and solutions and any future steps.
Here is an update for that with Karma:
Overall looking good, probably need to test with more pixel samples to remove noise.
And updated Mantra version with principle and fake caustics:
(still getting bucket shaped artefacts, not sure if that is the case of IP only in this H version 18.0.566)
Updated classic shader with caustic light (1000000 photons, 1000 filter samples)
I didn't want to wait 30mins for the render, so this is 20% of it:
I guess we would drop caustics approach nowadays ? (I could try cranking up photon amount, but that doesn't sounds like a solution)
Like I was mentioning - I know it's not an easy subject for a renderer(s) but want to explore all options and solutions and any future steps.
Here is an update for that with Karma:
Overall looking good, probably need to test with more pixel samples to remove noise.
And updated Mantra version with principle and fake caustics:
(still getting bucket shaped artefacts, not sure if that is the case of IP only in this H version 18.0.566)
Updated classic shader with caustic light (1000000 photons, 1000 filter samples)
I didn't want to wait 30mins for the render, so this is 20% of it:
I guess we would drop caustics approach nowadays ? (I could try cranking up photon amount, but that doesn't sounds like a solution)
Edited by tmdag - Oct. 15, 2020 14:03:16
Solaris and Karma » shadow capture
- tmdag
- 168 posts
- Offline
I am continuing investigation Houdini for a lighting purposes. This time a Shadow capture.
My goal is to capture shadow from a sphere onto the grid and from grid onto the sphere, but without grid SELF shadow contribution.
So this is a base object (8x8 pixel samples, 2 diffuse bounces):
So with Mantra, if we had to capture shadows for compositing, we would use “shadowmate” shader to store shadows within a separate rendered image on alpha channel:
This approach was annoying as it required separate material settings for an object - potentially set via Take or later introduced StyleSheets.
Also it did not took in consideration any diffuse bounces - it is just shadow or not shadow option.
So that way will definitely not work.
I could use “ShadowMask” on the light and disable ground - but that will also disable shadows casted onto the sphere - which is not a good solution:
With introduced ‘Render Visibility’ option we could choose “shadow” or “primary” or “secondary” rays for a specific object but that did not solve any need for a shadow pass.
With LPE and AOV passes, we could “ask” for “indirect_shadow” and “direct_shadow”:
I am getting some broken indirect shadow pass, but I am unable to choose where that shadow comes from.
Maybe there is more advanced LPE expression that could solve this issue for me ?
Now, lets switch to Karma (pixel samples 256 and diffuse bounces set to 2):
I'm getting different diffuse bounce effect than mantra, but ok, it's a different render. Just worried that look is much worse than mantra, that's all
Now lets set up shadow catcher.. We won't go with shadowmate as we have seen it's not going to work properly with diffuse bounces, so maybe LPEs or AOVs ?
To be honest, I am not even sure where to start as I don't see anything that would guide me towards shadow catching settings here:
Maybe someone of you have a good, tested workflow?
I know, i could probaby render some elements separately - one with sphere shadow and second with ground as phantom, shadowing sphere then put them together in Nuke - But this is my point - with such basic lighting manipulations we are looking for something more efficient that does not require lots of work in 3rd party applications.
My goal is to capture shadow from a sphere onto the grid and from grid onto the sphere, but without grid SELF shadow contribution.
So this is a base object (8x8 pixel samples, 2 diffuse bounces):
So with Mantra, if we had to capture shadows for compositing, we would use “shadowmate” shader to store shadows within a separate rendered image on alpha channel:
This approach was annoying as it required separate material settings for an object - potentially set via Take or later introduced StyleSheets.
Also it did not took in consideration any diffuse bounces - it is just shadow or not shadow option.
So that way will definitely not work.
I could use “ShadowMask” on the light and disable ground - but that will also disable shadows casted onto the sphere - which is not a good solution:
With introduced ‘Render Visibility’ option we could choose “shadow” or “primary” or “secondary” rays for a specific object but that did not solve any need for a shadow pass.
With LPE and AOV passes, we could “ask” for “indirect_shadow” and “direct_shadow”:
I am getting some broken indirect shadow pass, but I am unable to choose where that shadow comes from.
Maybe there is more advanced LPE expression that could solve this issue for me ?
Now, lets switch to Karma (pixel samples 256 and diffuse bounces set to 2):
I'm getting different diffuse bounce effect than mantra, but ok, it's a different render. Just worried that look is much worse than mantra, that's all
Now lets set up shadow catcher.. We won't go with shadowmate as we have seen it's not going to work properly with diffuse bounces, so maybe LPEs or AOVs ?
To be honest, I am not even sure where to start as I don't see anything that would guide me towards shadow catching settings here:
Maybe someone of you have a good, tested workflow?
I know, i could probaby render some elements separately - one with sphere shadow and second with ground as phantom, shadowing sphere then put them together in Nuke - But this is my point - with such basic lighting manipulations we are looking for something more efficient that does not require lots of work in 3rd party applications.
Edited by tmdag - Oct. 15, 2020 14:03:50
Solaris and Karma » transparency shadows
- tmdag
- 168 posts
- Offline
Hi!
As Houdini (solaris) is going towards serious lighting (which I am very happy about). I decided to start doing serious tests and ask serious lighting questions
All renders below were done using IPR on Houdini 18.0.566
#1 Transparency shadows.
With Mantra, transparency and shadows was always the issue. Even with Physical Rendering, we could not get proper shadows (and I understand, it's not a easy problem to solve).
starting as a “base” geometry :
(btw, please notice white line on the corners of inside of the box)
With a CLASSIC mantra shader, we would get effect like so:
Which of course, is a problem as shadow is way too dark for such transparent object.
Now, to deal with those shadows, we have 2 options:
#1 Totally remove shadows from equation (which could be sufficient for some scenarios but it's definitely not a “physically correct” solution)
or
#2 Calculate caustic light. In very simple example caustic light will work but in example like this one, it starts to fall apart:
(This render took >35mins, comparing to the previous one which took 30seconds, + it has tons of major issues)
Switching to the printipled shader, of course we will have same shadow issue (no caustic light):
With principled shader, SideFX has introduced “Fake Caustics” option which helps getting rid of bad shadows(no caustic light):
Now, switching to Karma - a base render with 1 diffuse bounce (same as mantra) gave little bit different result:
Adding transparent glass object to it (with principle “fake caustics”):
My question is - is there something I am doing wrong in my setup, something that I am missing or I should do other way ?
How do You approach an issue with transparent shadows in your scenes ?
Don't want to compare to other renderers here, but Mantra and Karma is not performing well and I want to make sure I am not doing anything wrong before treating it as a formal bug.
As Houdini (solaris) is going towards serious lighting (which I am very happy about). I decided to start doing serious tests and ask serious lighting questions
All renders below were done using IPR on Houdini 18.0.566
#1 Transparency shadows.
With Mantra, transparency and shadows was always the issue. Even with Physical Rendering, we could not get proper shadows (and I understand, it's not a easy problem to solve).
starting as a “base” geometry :
(btw, please notice white line on the corners of inside of the box)
With a CLASSIC mantra shader, we would get effect like so:
Which of course, is a problem as shadow is way too dark for such transparent object.
Now, to deal with those shadows, we have 2 options:
#1 Totally remove shadows from equation (which could be sufficient for some scenarios but it's definitely not a “physically correct” solution)
or
#2 Calculate caustic light. In very simple example caustic light will work but in example like this one, it starts to fall apart:
(This render took >35mins, comparing to the previous one which took 30seconds, + it has tons of major issues)
Switching to the printipled shader, of course we will have same shadow issue (no caustic light):
With principled shader, SideFX has introduced “Fake Caustics” option which helps getting rid of bad shadows(no caustic light):
Now, switching to Karma - a base render with 1 diffuse bounce (same as mantra) gave little bit different result:
Adding transparent glass object to it (with principle “fake caustics”):
My question is - is there something I am doing wrong in my setup, something that I am missing or I should do other way ?
How do You approach an issue with transparent shadows in your scenes ?
Don't want to compare to other renderers here, but Mantra and Karma is not performing well and I want to make sure I am not doing anything wrong before treating it as a formal bug.
Edited by tmdag - Oct. 15, 2020 13:59:12
Houdini Engine for Unreal » Houdini Engine Plugin not loading in source version
- tmdag
- 168 posts
- Offline
Found this thread by googling as well
Thanks for tips, now it loads on linux properly!
Maybe we could clarify on the github page:
4. Source houdini variables making sure $HFS variable points to correct Houdini build. Alternatively, you can set a custom Houdini path in the project settings, under Houdini Engine, “Custom Houdini Location”.
5. Generate the UE4 Project Files (by running GenerateProjectFiles.sh from Unreal Source folder)
6. Build Unreal, either in x64 Debug Editor or x64 Development Editor.
Thanks for tips, now it loads on linux properly!
Maybe we could clarify on the github page:
4. Source houdini variables making sure $HFS variable points to correct Houdini build. Alternatively, you can set a custom Houdini path in the project settings, under Houdini Engine, “Custom Houdini Location”.
5. Generate the UE4 Project Files (by running GenerateProjectFiles.sh from Unreal Source folder)
6. Build Unreal, either in x64 Debug Editor or x64 Development Editor.
Technical Discussion » houdini 16 crashes on start up
- tmdag
- 168 posts
- Offline
updated my previous post.
Sidefx helped with solution:
add ‘HOUDINI_USE_HFS_PYTHON=1’ to houdini.env file and that fixed my problems.
Sidefx helped with solution:
add ‘HOUDINI_USE_HFS_PYTHON=1’ to houdini.env file and that fixed my problems.
Technical Discussion » houdini 16 crashes on start up
- tmdag
- 168 posts
- Offline
Having problems as well with fresh Fedora 26. Centos 7 was fine-ish (had to change NVIDIA driver version)
So far I have tested:
Houdini: 16.0.633, 16.0.671, 16.0.671 QT4, 16.0.680, 16.0.682, 16.0.683
Nvidia: 375.66, 384.47, 381.22, 375.82, 384.59
Results more or less the same (crashes on start)
Solution: add ‘HOUDINI_USE_HFS_PYTHON=1’ to houdini.env file
Example:
Houdini 16.0.683
System Fedora26 (4.11.11-300.fc26.x86_64)
Nvidia: 375.66
> houdini
So far I have tested:
Houdini: 16.0.633, 16.0.671, 16.0.671 QT4, 16.0.680, 16.0.682, 16.0.683
Nvidia: 375.66, 384.47, 381.22, 375.82, 384.59
Results more or less the same (crashes on start)
Solution: add ‘HOUDINI_USE_HFS_PYTHON=1’ to houdini.env file
Example:
Houdini 16.0.683
System Fedora26 (4.11.11-300.fc26.x86_64)
Nvidia: 375.66
> houdini
Could not initialize the help server: Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/opt/hfs16.0.683/houdini/python2.7libs/houdinihelp/__init__.py", line 1, in <module> from houdinihelp.api import * File "/opt/hfs16.0.683/houdini/python2.7libs/houdinihelp/api.py", line 8, in <module> from bookish import paths, textify, util, functions, stores File "/opt/hfs16.0.683/houdini/python2.7libs/bookish/textify.py", line 31, in <module> from bookish import compat, util File "/opt/hfs16.0.683/houdini/python2.7libs/bookish/util.py", line 35, in <module> import shutil SystemError: NULL result without error in PyObject_Call 5403: Fatal error: Segmentation fault (sent by pid 40) Crash log saved to /tmp/houdini_temp/crash.ats_5403_log.txt > cat /tmp/houdini_temp/crash.ats_5403_log.txt Crash report from ats; Unknown App Version 16.0.683 [linux-x86_64-gcc4.8] Uptime 0 seconds Tue Aug 1 04:38:44 2017 Caught signal 11 Traceback from 5403 ThreadId=0x7f1833de2d00 AP_Interface::coreDumpChaser(UTsignalHandlerArg) <libHoudiniUI.so> AP_Interface::si_CrashHandler::chaser(UTsignalHandlerArg) <libHoudiniUI.so> signalCallback(UTsignalHandlerArg) <libHoudiniUT.so> UT_Signal::UT_ComboSignalHandler:perator()(int, siginfo*, void*) const <libHoudiniUT.so> UT_Signal::processSignal(int, siginfo*, void*) <libHoudiniUT.so> __funlockfile <libpthread.so.0> je_arena_dalloc_bin_locked (arena.c:1897) je_tcache_bin_flush_small (tcache.c:127) je_tcache_event_hard (tcache.c:39) malloc (tcache.h:271) UT_StringRef::Holder::build(char const*, UT_StringRef:torageMode) <libHoudiniUT.so> UT_UIOptionParser::parseLine(char const*, UT_SymbolMap<UT_StringHolder>&) <libHoudiniUT.so> UT_UIOptionParser::load(char const*, UT_IStream&, UT_SymbolMap<UT_StringHolder>&) <libHoudiniUT.so> UT_OptionFile::load(char const*, UT_IStream&) <libHoudiniUT.so> UT_OptionFile::load(char const*) <libHoudiniUT.so> UI_IconBase::fetch(char const*, bool, UI_IconScalability, bool, bool) <libHoudiniUI.so> UI_Icon::UI_Icon(char const*, UI_BorderType) <libHoudiniUI.so> UI_IconButtonLook::UI_IconButtonLook(char const*, bool) <libHoudiniUI.so> SI_HelpButton::setDefaultLook() <libHoudiniUI.so> si_parse(SI_Parse*) <libHoudiniUI.so> SI_Parse::parse(_IO_FILE*, char const*, bool) <libHoudiniUI.so> AP_Interface::readUIFile(char const*, bool) <libHoudiniUI.so> FUSE_ColorOptions::initApplication(UI_Manager*, int, char const**) <libHoudiniAPPS3.so> FUSE_ColorOptions::FUSE_ColorOptions() <libHoudiniAPPS3.so> FUSE_ColorOptions::dialog() <libHoudiniAPPS3.so> FUSE_App::FUSE_App(char const*) <libHoudiniAPPS3.so> FUSE_HoudiniBinariesApp::createApplication(int&, char const**) <libHoudiniAPPS3.so> OPUI_MainApp::initApplication(UI_Manager*, int, char const**) <libHoudiniAPPS2.so> main <libHoudiniUI.so> __libc_start_main <libc.so.6> _start <houdini-bin>
Edited by tmdag - Aug. 1, 2017 15:07:44
Houdini Lounge » Getting .pem key to instance on HQueue
- tmdag
- 168 posts
- Offline
got it, just needed to read manual carefully
To ssh to a cloud machine, you need to know the path to your ssh key and the machine’s name.
Amazon uses passwordless ssh keys which are stored in your $HOME/houdiniX.Y/aws directory ( $HOME/Library/Preferences/Houdini/X.Y on the Mac), where X.Y is the Houdini
version. The key is named userid-ssh-key.rsa and corresponds to the instance keypair
name that appears in the Amazon AWS Web Console beside the instance.
You can find the cloud server machine name by looking at the Public DNS field in the Amazon
Web Console.
To ssh in using the key, run ssh -i $HOME/houdiniX.Y/aws/userid-ssh-key.rsa
root@ec2-XXX-XXX-XXX-XXX.compute-1.amazonaws.com.
To ssh to a cloud machine, you need to know the path to your ssh key and the machine’s name.
Amazon uses passwordless ssh keys which are stored in your $HOME/houdiniX.Y/aws directory ( $HOME/Library/Preferences/Houdini/X.Y on the Mac), where X.Y is the Houdini
version. The key is named userid-ssh-key.rsa and corresponds to the instance keypair
name that appears in the Amazon AWS Web Console beside the instance.
You can find the cloud server machine name by looking at the Public DNS field in the Amazon
Web Console.
To ssh in using the key, run ssh -i $HOME/houdiniX.Y/aws/userid-ssh-key.rsa
root@ec2-XXX-XXX-XXX-XXX.compute-1.amazonaws.com.
Houdini Lounge » Getting .pem key to instance on HQueue
- tmdag
- 168 posts
- Offline
Hi,
Once HQueue runs instance, .pem key is being created. Is there a way to get that key so I could ssh to instance?
Thanks!
Once HQueue runs instance, .pem key is being created. Is there a way to get that key so I could ssh to instance?
Thanks!
Technical Discussion » Creating curves using open edges...
- tmdag
- 168 posts
- Offline
connectivity sop might help you with that - it will create attribute based on connectivity, then you can group objects. then you can use partition sop to create groups based on that attribute
Houdini Learning Materials » Sculpted Particle Fluid - Terrain
- tmdag
- 168 posts
- Offline
Technical Discussion » Particle Manipulation Help
- tmdag
- 168 posts
- Offline
I understand what you are trying to achieve but we don't know what you might be “punching” wrong
if it is a pop sim, there is an option to add randomisation in every axis on source node.
if it is a pop sim, there is an option to add randomisation in every axis on source node.
Technical Discussion » Particle Manipulation Help
- tmdag
- 168 posts
- Offline
Houdini Learning Materials » Sculpted Particle Fluid - Terrain
- tmdag
- 168 posts
- Offline
there was a problem with cookie sop in “River_sculpted_setup” sop
I have added extrude volume and decreased particle separation from 20 to 1
I have added extrude volume and decreased particle separation from 20 to 1
Technical Discussion » Group the primitives that were hit by "Intersect"
- tmdag
- 168 posts
- Offline
-
- Quick Links