Found 11 posts.
Search results Show results as topic list.
Technical Discussion » Fire flies in pyro_fire and pyro_fire_mask but not beauty
- pskaifa
- 11 posts
- Offline
An isuue I haven't noticed before just popped up in most of my pyro renders. The compositor noticed that there is significant noise and/or fireflies in the pyro fire and fire mask aovs when using pyrobakevolume in H18.596. Has anyone experienced this? I thought I could get away with it for distance shots but it seems that the bright spots just become even more prominent. Also, I tested it with multiple overlapping wedges as well as a single container close up: same issue. I am not able to post a file or any images unfortunately.
Technical Discussion » Vellum sim broken on a specific shot, but not others
- pskaifa
- 11 posts
- Offline
ok looks like transforming the assets manually closer to the origin at the SOP level worked! thanks!!! @tamte
Technical Discussion » Vellum sim broken on a specific shot, but not others
- pskaifa
- 11 posts
- Offline
sorry, here is what it is suppposed to look like (I posted the wrong pic above). I will try deleting the attributes too, but it is strange that it has been working without issue for months. The only difference I can see is the distance from the orgin in the new shot.
Technical Discussion » Vellum sim broken on a specific shot, but not others
- pskaifa
- 11 posts
- Offline
Technical Discussion » Vellum sim broken on a specific shot, but not others
- pskaifa
- 11 posts
- Offline
Hey guys,
So have been working on a vellum paper sim on a bunch (+50) shots. Everything was going well until one specific scene where the sim breaks. As you can see I am getting "tenting" and garbled pieces everywhere.
Overview: So I am using a scatter, popnet, copy to points , vellum constraints, then feeding into the vellum solver (SOP), applying wind, drag and noise etc. It is a very simple set up. Suddenly on a new shot with different positions (more on that later) on the assets (collision objects etc) I started getting artifacts so I deleted everything and copied a set up from a working scene. I tested the working scene and the new scene side by side with the same source for the paper notes (from lookdev): but the new scene was still broken. Then I took the working scene and "saved as" into the folder of the broken shot, and just replaced the emitter plane, same thing: broken. The funny thing is that if I used the old emitter plane, it works, but as soon as I animated it to match the shot it breaks again. I repeated this a bunch of times with no luck. The only difference that I could see between the working scene and the broken scene was the position of the assets. In the working scene they are about 50 units from the origin at a scale of 0.01, but for the broken scene they are 650 units from the origin (after scaling down by 0.01). Of course I tried to transform the whole scene with a null to the orgin to test but that didn't work either. Has anyone ever had a similar issue?
So have been working on a vellum paper sim on a bunch (+50) shots. Everything was going well until one specific scene where the sim breaks. As you can see I am getting "tenting" and garbled pieces everywhere.
Overview: So I am using a scatter, popnet, copy to points , vellum constraints, then feeding into the vellum solver (SOP), applying wind, drag and noise etc. It is a very simple set up. Suddenly on a new shot with different positions (more on that later) on the assets (collision objects etc) I started getting artifacts so I deleted everything and copied a set up from a working scene. I tested the working scene and the new scene side by side with the same source for the paper notes (from lookdev): but the new scene was still broken. Then I took the working scene and "saved as" into the folder of the broken shot, and just replaced the emitter plane, same thing: broken. The funny thing is that if I used the old emitter plane, it works, but as soon as I animated it to match the shot it breaks again. I repeated this a bunch of times with no luck. The only difference that I could see between the working scene and the broken scene was the position of the assets. In the working scene they are about 50 units from the origin at a scale of 0.01, but for the broken scene they are 650 units from the origin (after scaling down by 0.01). Of course I tried to transform the whole scene with a null to the orgin to test but that didn't work either. Has anyone ever had a similar issue?
Technical Discussion » No motionblur for Alembic export to Maya rendered in vray
- pskaifa
- 11 posts
- Offline
Thanks this works. I never had to use except for redshift with a flipmesh, but really good to know that it works for RBD with disconnectedfaces too.
Cheers
Cheers
Technical Discussion » No motionblur for Alembic export to Maya rendered in vray
- pskaifa
- 11 posts
- Offline
Issue overview: recently I have been using the H18.5 rbdbulletsolver workflow, particularly for glass destruction using the rbdconnected/disconnected faces to hide the prefactured faces. It has worked very well for many shots when exporting the alembics separately for example: Show_shot_fx_glass.abc and Show_shot_fx_frames.abc. However on this show the lookdev guys are requiring it to be merged together into a single alembic before export so that it has the identical path and hierarchy in Maya. After alot of fanagling I got that all to work by deleting all groups and unneccessary attributes, enabling path att, and motionblur etc. The uvs are coming through correctly with inside faces transformed to the second tile as requested. Rbddisconnectedfaces is working as planned. Velocity is there as a point attribute. The problem is that the motionblur (mb) is not working. In one iteration mb worked for one layer, and not the other. Now it is not working for either layer. When I load the alembic and try to render (vray)I get warnings about changing vertex counts. I read somewhere online that I might have to promote the v to a vertex attr with attribute promote. I tried that but still no luck. When I loaded it as a vray proxy the motionblur worked, so the v data must be getting in there! Problem is that lookdev doesn't want to change their workflow. Hoping someone has had the same/similar issue and can point me in the right direction, or provide some food for thought. thanks in advance.
Houdini 18.5 workflow
Glass destruction prep
-Geo Input: alembic model with glass and frame layers separated with blasts by name
-layer1 glass: rbdmaterialfracture/glass (named glass)
-layer2 concrete: rbdmaterialfracture/concrete (named frame)
-unwrap and transform inside faces to second udim
-rbdconnected/disconnected faces
sim: rbdbulletsolver (SOP level)
ouput: rbdio>>transformpieces + rest
split output back into two layers via blast: @name=glass* @name=glass* not
for both layers process before export:
-attribute delete* ^N, ^v, ^path, ^uv etc
-group delete (all groups)
-transform x100
**edit** clean sop with "remove unused points"
-merge both layers into same stream then export as alembic:
Alembic ROP
-path attribute: path: build heirarchy from attribute
-Motionblur: check "use motionblur"
Load alembic in Maya
-path is correct
-heirarchy is correct
-uvs are correct
-enabled motionblur in overrides
-Maya is throwing a warning about changing vertex counts.
-Looked into promoting the v to vertex using attribute promote no luck
-mb works with vray proxy but not when loading as a standard cache/alembic import
Houdini 18.5 workflow
Glass destruction prep
-Geo Input: alembic model with glass and frame layers separated with blasts by name
-layer1 glass: rbdmaterialfracture/glass (named glass)
-layer2 concrete: rbdmaterialfracture/concrete (named frame)
-unwrap and transform inside faces to second udim
-rbdconnected/disconnected faces
sim: rbdbulletsolver (SOP level)
ouput: rbdio>>transformpieces + rest
split output back into two layers via blast: @name=glass* @name=glass* not
for both layers process before export:
-attribute delete* ^N, ^v, ^path, ^uv etc
-group delete (all groups)
-transform x100
**edit** clean sop with "remove unused points"
-merge both layers into same stream then export as alembic:
Alembic ROP
-path attribute: path: build heirarchy from attribute
-Motionblur: check "use motionblur"
Load alembic in Maya
-path is correct
-heirarchy is correct
-uvs are correct
-enabled motionblur in overrides
-Maya is throwing a warning about changing vertex counts.
-Looked into promoting the v to vertex using attribute promote no luck
-mb works with vray proxy but not when loading as a standard cache/alembic import
Edited by pskaifa - 2022年5月7日 21:12:52
Technical Discussion » Copy to points, random geo selection and offset uvs problem
- pskaifa
- 11 posts
- Offline
So I think I figured it out. It was really simple as you said. In my variant wrangle I had i@variant = int(rand(@ptnum)*4);
I should have replaced the @ptnum with @id so i@variant = int(rand(@id)*4);
It was your suggestion to transfer the variant attr that got me looking into the values in the geo spreadsheet, where I noticed they were changing despite having set the id = ptnum, so then I noticed I was still using ptnum. Thanks
I should have replaced the @ptnum with @id so i@variant = int(rand(@id)*4);
It was your suggestion to transfer the variant attr that got me looking into the values in the geo spreadsheet, where I noticed they were changing despite having set the id = ptnum, so then I noticed I was still using ptnum. Thanks
Technical Discussion » Copy to points, random geo selection and offset uvs problem
- pskaifa
- 11 posts
- Offline
Hey Tomas, thanks for the quick reply. Going to test some of your ideas today and report back.
Cheers
Cheers
Technical Discussion » Copy to points, random geo selection and offset uvs problem
- pskaifa
- 11 posts
- Offline
First, I am not able to post the file yet since it is at work, but I may be able to later when I get some time to replicate the issue from my home computer. Hoping it is something simple I am overlooking.
Description of set up: pretty basic set up scattering points as a source for a POP network (justborn), then copy to points using an i@variant wrangle to randomly select 4 alembic variations from lookdev, then feeding that into a vellum cloth set up. This is a set up for money flying out of a car with 4 dollar denominations.
The variations are using the same shader set up from lookdev, each with offset UVs that access the next tile (udim) one for each bill denomination. When I check each variation at this point the uvs are displaying correctly in the uv viewport. When merged, I can see all 4 offset uv sets correctly. Next, Each variation is packed with the uv attribute transfered, fed in to the copy to points with the piece attribute enabled.
After the copy to points I am unpacking, and doing another check. This is where the problem starts. when I check the uvs at this point there is one tile missing (the 3rd). After exporting to Alembic that same tile is missing in Maya, so every third dollar bill is missing the uvs.
Test #1. thinking there was a problem with the i@variant method, I decided to test with a foreach with a switch node instead. The result was the exact same problem.
Test #2. I decided to use just one geometry variation and then use a uv transform to access the other tiles: same problem
Test #3 I decided to test using groups, assigning each variation to a group thinking that I could blast them away and/or provide lighting with the group info so they could apply separate materials based on those groups.
I got a really weird result: similar to the missing 3rd uv tile, the 3rd group was empty. Even more weird was if I added a 5th group then the 4th group was empty but the 5th group contained data. So I thought that I could just provide groups 1, 2, 3, and 5. Except that when I checked uv tiles were there but they not match the input and were shifting around tiles randomly.
I was thinking that it was a changing ptnum issue, but I already had an @id=@ptnum; wrangle but that didn't work.
Now I am thinking it is a detail attribute thing since it is uvs per copy that I am trying to preserve, but not 100% sure how to go about that, or if I am on the correct path here. Any advice would be much appreciated.
Description of set up: pretty basic set up scattering points as a source for a POP network (justborn), then copy to points using an i@variant wrangle to randomly select 4 alembic variations from lookdev, then feeding that into a vellum cloth set up. This is a set up for money flying out of a car with 4 dollar denominations.
The variations are using the same shader set up from lookdev, each with offset UVs that access the next tile (udim) one for each bill denomination. When I check each variation at this point the uvs are displaying correctly in the uv viewport. When merged, I can see all 4 offset uv sets correctly. Next, Each variation is packed with the uv attribute transfered, fed in to the copy to points with the piece attribute enabled.
After the copy to points I am unpacking, and doing another check. This is where the problem starts. when I check the uvs at this point there is one tile missing (the 3rd). After exporting to Alembic that same tile is missing in Maya, so every third dollar bill is missing the uvs.
Test #1. thinking there was a problem with the i@variant method, I decided to test with a foreach with a switch node instead. The result was the exact same problem.
Test #2. I decided to use just one geometry variation and then use a uv transform to access the other tiles: same problem
Test #3 I decided to test using groups, assigning each variation to a group thinking that I could blast them away and/or provide lighting with the group info so they could apply separate materials based on those groups.
I got a really weird result: similar to the missing 3rd uv tile, the 3rd group was empty. Even more weird was if I added a 5th group then the 4th group was empty but the 5th group contained data. So I thought that I could just provide groups 1, 2, 3, and 5. Except that when I checked uv tiles were there but they not match the input and were shifting around tiles randomly.
I was thinking that it was a changing ptnum issue, but I already had an @id=@ptnum; wrangle but that didn't work.
Now I am thinking it is a detail attribute thing since it is uvs per copy that I am trying to preserve, but not 100% sure how to go about that, or if I am on the correct path here. Any advice would be much appreciated.
Technical Discussion » Rendering with Pyro Bake Volume (using pyro burst set up)
- pskaifa
- 11 posts
- Offline
Hello sidefx,
I have been using the new 18.5 pyroburstsource and pyrobakevolume combo (awesome tool btw), on a production shot. Everything has been working well and it has made it a lot faster to turn around large clusters of explosions with trails etc. The only issue I am having is that I cannot figure out use packed disk primitives when sending to the farm. In the old pyro I would just do my post sim tweaks after the dopimport and then cache after that. The then I would set the cache to packed disk prims and all would be good.
For H18.5 pyro I am caching after the pyrobakevolume, but when I submit to the farm it only renders the density, even though I can see that I have temperature, flame, trail-temperature, scatter, and density all present.
If I render unpacked, it does render correctly but for some reason (licensing?) it takes eons. I am getting down to the wire and need to have a way to render these layers faster with the normal packed prim work flow. Any thoughts?
I have been using the new 18.5 pyroburstsource and pyrobakevolume combo (awesome tool btw), on a production shot. Everything has been working well and it has made it a lot faster to turn around large clusters of explosions with trails etc. The only issue I am having is that I cannot figure out use packed disk primitives when sending to the farm. In the old pyro I would just do my post sim tweaks after the dopimport and then cache after that. The then I would set the cache to packed disk prims and all would be good.
For H18.5 pyro I am caching after the pyrobakevolume, but when I submit to the farm it only renders the density, even though I can see that I have temperature, flame, trail-temperature, scatter, and density all present.
If I render unpacked, it does render correctly but for some reason (licensing?) it takes eons. I am getting down to the wire and need to have a way to render these layers faster with the normal packed prim work flow. Any thoughts?
-
- Quick Links