Hi, It seems the foreach node “moved” one of the input polygons and put in on top of the adjacent polygon after the node finishes the calculations embedded inside (see images below).
It seems as long as I have more than one polygon, the foreach node will move the last one and overlap it with the second last one…
Can anyone pls kindly advise why this happens?
Thanks!
- Ji
[solved] foreach node messed up polygons
3789 9 2
-
- oat
- Member
- 479 posts
- Joined: Dec. 2009
- Offline
-
- zarti
- Member
- 330 posts
- Joined: July 2007
- Offline
-
- oat
- Member
- 479 posts
- Joined: Dec. 2009
- Offline
-
- zarti
- Member
- 330 posts
- Joined: July 2007
- Offline
strange , at the begining i thought the culprit could be the Connectivity SOP .
iirc , i replaced it with an attribcreate SOP generating the same attribute foreach was refering to .. connected both with a switch node to see any difference comming from connectivity .
maybe the attribute was comming from attribcreate when the output was ok , but i doubt . maybe i can retry later when i have Hou in front again .
iirc , i replaced it with an attribcreate SOP generating the same attribute foreach was refering to .. connected both with a switch node to see any difference comming from connectivity .
maybe the attribute was comming from attribcreate when the output was ok , but i doubt . maybe i can retry later when i have Hou in front again .
except the things that cannot be seen , nothing is like it seems .
-
- tjeeds
- Member
- 339 posts
- Joined: Aug. 2007
- Offline
This might be a bug or the ForEach may simply not work this way, but it appears that the culprit is the nested ForEach that runs on points. I would trash that and instead do a forloop in a vopsop, you're just running vops inside there anyway, no need for the extra complexity.
May I ask what the final goal is here, it's lookin' wacky and there may be a simpler way to approach it.
May I ask what the final goal is here, it's lookin' wacky and there may be a simpler way to approach it.
Jesse Erickson
Fx Animator
WDAS
Fx Animator
WDAS
-
- zarti
- Member
- 330 posts
- Joined: July 2007
- Offline
oat
..
it seems the calculation performed for each of the polygons is still correct, it's just that the last polygon will be moved strongly and lay on top of the second last one…
- Ji
try this ;
- replace connectivity with an attribcreate
- put $PR + 1 on its first value ( yep! just add 1 )
- keep the name of attribute you assigned to connectivity
here this works . i changed the grid 's rows and columns and this way it keeps working .
maybe something wrong with zeros when doing foreach inside another foreach ? .. or maybe a bug ? not sure , but hope this works at least for your actual project .
.cheers
except the things that cannot be seen , nothing is like it seems .
-
- oat
- Member
- 479 posts
- Joined: Dec. 2009
- Offline
Hi, Zarti, thanks a lot for your suggestion! it works (see attached cumu_dir_irradi_ZartiWay_v003.hipnc)
To tjeeds,
Hi, I agree with you that my approach is messy. I'm following your suggestion to use just one foreach node and use vopsop inside it… However I doesn't seem to get it work correctly, can you kindly help to take a look of the hip file I attached here? (cumu_dir_irradi_via_VOP_v003.hipnc)
What I want to do is to get the "cumulative effective radiance from multiple suns for each sensor on a surface“ which is explained via the following images (in Zarti's approach):
1. suppose we have 2 points representing two sun positions with their radiance values embedded as point attrib
2. the sensors are the centroids of the polygons in a grid
3. the context (obstruction) consists of the grid and a tall building
What I did previously are:
4. use the foreach node to calculate the ”cumulative effective radiance“ for each sensor (polygon) taking into consideration of the context
5. inside the foreach node, copy the suns to the centroid of the current polygon
6. for each sun, we use a VOPSOP to get 1) it's visibility from sensor, 2) its ”effective radiance contribution without obstruction“, and then each sun's ”actual effective radiance contribution“ to the current sensor is ”effective radiance contribution without obstruction“ multiplied by ”visibility“
7. get the sum of the ”actual effective radiance contribution“ from all suns, and pass that attrib to the current polygon
8. visualize the ”actual effective radiance contribution" for all the polygons
Hope I have explained my idea clearly….
- Ji
To tjeeds,
Hi, I agree with you that my approach is messy. I'm following your suggestion to use just one foreach node and use vopsop inside it… However I doesn't seem to get it work correctly, can you kindly help to take a look of the hip file I attached here? (cumu_dir_irradi_via_VOP_v003.hipnc)
What I want to do is to get the "cumulative effective radiance from multiple suns for each sensor on a surface“ which is explained via the following images (in Zarti's approach):
1. suppose we have 2 points representing two sun positions with their radiance values embedded as point attrib
2. the sensors are the centroids of the polygons in a grid
3. the context (obstruction) consists of the grid and a tall building
What I did previously are:
4. use the foreach node to calculate the ”cumulative effective radiance“ for each sensor (polygon) taking into consideration of the context
5. inside the foreach node, copy the suns to the centroid of the current polygon
6. for each sun, we use a VOPSOP to get 1) it's visibility from sensor, 2) its ”effective radiance contribution without obstruction“, and then each sun's ”actual effective radiance contribution“ to the current sensor is ”effective radiance contribution without obstruction“ multiplied by ”visibility“
7. get the sum of the ”actual effective radiance contribution“ from all suns, and pass that attrib to the current polygon
8. visualize the ”actual effective radiance contribution" for all the polygons
Hope I have explained my idea clearly….
- Ji
-
- oat
- Member
- 479 posts
- Joined: Dec. 2009
- Offline
-
- edward
- Member
- 7734 posts
- Joined: July 2005
- Online
oat
Hi, It seems the foreach node “moved” one of the input polygons and put in on top of the adjacent polygon after the node finishes the calculations embedded inside (see images below).
I think this might be a bug you should submit. If I load your .hip file, turn off “Merge Results” and then back on again, then it seems to cook fine.
-
- oat
- Member
- 479 posts
- Joined: Dec. 2009
- Offline
thanks, edward!
According to the Houdini team it is not a bug:
Side Effects Support Ticket: #7464
Hello,
This is not a bug. When you nest foreach sops, you have to rename the stamp name variables in the nested foreach, or they might evaluate erroneously.
So, in your hip file, in the calc_contribution_from_each_source_pts node, please rename the Stamp Name MYVALUE (or something else of your choice) and the Index Stamp Name MYIDXVALUE.
Cheers,
Support
Thanks, Houdini team!
J
According to the Houdini team it is not a bug:
Side Effects Support Ticket: #7464
Hello,
This is not a bug. When you nest foreach sops, you have to rename the stamp name variables in the nested foreach, or they might evaluate erroneously.
So, in your hip file, in the calc_contribution_from_each_source_pts node, please rename the Stamp Name MYVALUE (or something else of your choice) and the Index Stamp Name MYIDXVALUE.
Cheers,
Support
Thanks, Houdini team!
J
-
- Quick Links