Good question -- the center of rotation in this example is the actual instance position point. If you wanted each point to rotate at an offset position from that center point, you'd need to: STEP 1: subtract the offset vector position (your desired center of rotation) from the current instance position. //Code v@offset = set(0,0,0); @P -= v@offset; STEP 2: apply your rotation to your normal/up vectors/ Rotations in vex can be done like this: // Throw in point wrangle ---- vector normal = @N; vector axis = v@up; float angle = 0; vector4 quat = quaternion(radians(angle),axis); matrix3 m = qconvert(quat); normal *= m; @P *= m; //end of vex code STEP 3: then add back the offset vector position. //Code @P += v@offset; ------ That may have some errors in it, but that's the main concept. Give that a try, and see if it works. I didn't test it, but that's the gist of what I'd do.
At the end of the day, packed geo is the same whether it is instanced with the instance sop, or whether you check "pack geo" on the copy sop. A packed geometry is simple a reference to a specific geo. For example, say you have a model with 10,000 polygons. If you copy it to 100 points with the copy sop, WITHOUT checking packed geo, it will essentially duplicate that 10,000 poly model, 100 times. This would result it 1,000,000 polygons that all take up space in memory. However, if you pack the geo, then it references only 10,000 polys in memory, yet you can have 100 instances of that high poly geo. So using the copy sop to pack, just locally packs the input of the copy sop, and the instance sop essentially loads whatever you are instancing as if it were a file. Hopefully this helps?
nope, I don't believe it should matter@@g8610g -- just middle mouse click on your node after the instance or copy sop and ensure it says something like "100 pack ed primitive" or "100 packed discs" and you should most likely be good -- I say most likely only because I can't 100% verify your scene, but that's the basic concept around packed geometry. :)
@@mrbennelson Hi I'm learning a lot from your videos! Thank you for the contents. I was also wondering how different it is from the copytopoint pack and instance. So you're saying it works almost the same way except the instance node takes a file format?
@@user-sl309jd90 yep, basically. You can instance geometry on the opposite input of the copytopoint node. In fact, you can actually copy n number of geometries to pack and instance onto points based on a name attribute. For example, say you have 10 points and 3 different versions of a brick, if you assign each an s@name attribute "piece_0", "piece_1" or "piece_2" -- Then just plug in the 3 bricks to the other input, but make sure each brick also has a unique name matching those points i.e. "piece_0" ... "piece_2" Check "pack and instance" and bam, you can then copy as many bricks as you want but it'll only reference the 3 bricks, as opposed to literally copying the polygons. I hope that makes sense? Sorry for the novel.
Hey man, great tutorial, one question, if I want to render with Redshift, how would I go about creating the instances and such for it to work with RS? Thanks man
For that, you'd follow a similar approach here, one difference would be put each brick version in it's own object level sop, and then name your instance attribute on the points something like: s@instance = /obj/brick_01 or to randomize the path, you could do something like: s@instance = "/obj/brick_0" + itoa(int(fit01(rand(@ptnum),1,6))); This would be the case if you had 5 sop level bricks, all labeled brick_01 to brick_05 So then from there you should be able to render the points in redshift as instance points, and they should point properly to the object level geo sops you have. One last note, you'd need to make sure your bricks have Redshift materials, as opposed to Houdini Mantra materials. --- I know this is brief, I potentially could have missed a slight step or two, just this was off the top of my head, but I hope it points you in the right direction!
@@mrbennelson thanks I really appreciate that! One more thing though, so what I'm looking to do with this is an RDB shot, but I understand these bricks are way too high res for that, right? I would really need to optimize them to do that I'm assuming
So the best approach for something like that would be to use proxy geo in your sim, and then transform the high res geo for final render.@@estebanvasco3172 To do this has a test, grab one high res brick geo, drop down a bound sop, so it turns it into a low res "proxy geo" of your brick. Use an assemble node, and check "pack geometry" -- then pipe that into your rbd sim, and simulate. Grab the high res brick, pack it and make sure its name attribute is the same as the simmed low res brick and pipe it into a "transform pieces" node. Then pipe the rbd simmed low res brick into the second input and it should transform your high res brick exactly how the low res is simmed. (You may need to pipe in the first frame only of the sim into the 3rd input) But yeah that's a gist of using a low res geo in sim, but then rendering with the high res geo.
you know I hear that a lot -- I really need to do that. I want to help teach but of course gotta get some funding to do so. Eventually I want to launch some consistent, paid content that is worth the purchase. That's easier said than done though, I'm working on it! Quick question -- would you prefer long form courses that are like 4 hours long or just like bit size 10 - 20 minute videos that are cheaper to buy? I've been toying with what sort of content to offer and having feedback is valuable!
@@mrbennelson Oh, I understand, the funding is an issue alright. But one step at a time! Glad to hear you're moving to that direction, because your content will worth it, in my opinion. The 4 hour long course distributed as a playlist of 10-20 min videos is much easier to go through. I don't mind both types as long there's consistency in learning. I would take a longer course to grasp the foundational & intermediate things of VEX, for instance, and would look for shorter videos to learn more of advanced concepts. Maybe, that's how it's usually done, hah. Else, do catchy snippets for social media. Anyways, I find your style to be very cool. Many people might benefit from what you'll make!
Thank you! That was incredibly helpful!
So good man, thank you.
You're welcome!
Thank You very much!
Terrific !!💫 🚀
Amazing content bro!
Thank you! Glad you like it.
If I wanted to adjust the center rotation of each brick procedurally how would I go about doing that?
Good question -- the center of rotation in this example is the actual instance position point. If you wanted each point to rotate at an offset position from that center point, you'd need to:
STEP 1: subtract the offset vector position (your desired center of rotation) from the current instance position.
//Code
v@offset = set(0,0,0);
@P -= v@offset;
STEP 2: apply your rotation to your normal/up vectors/ Rotations in vex can be done like this:
// Throw in point wrangle ----
vector normal = @N;
vector axis = v@up;
float angle = 0;
vector4 quat = quaternion(radians(angle),axis);
matrix3 m = qconvert(quat);
normal *= m;
@P *= m;
//end of vex code
STEP 3: then add back the offset vector position.
//Code
@P += v@offset;
------
That may have some errors in it, but that's the main concept. Give that a try, and see if it works. I didn't test it, but that's the gist of what I'd do.
What is the difference between this and just selecting "packed geo" checkbox in copy to points node and copy& transform nodes?
At the end of the day, packed geo is the same whether it is instanced with the instance sop, or whether you check "pack geo" on the copy sop. A packed geometry is simple a reference to a specific geo.
For example, say you have a model with 10,000 polygons. If you copy it to 100 points with the copy sop, WITHOUT checking packed geo, it will essentially duplicate that 10,000 poly model, 100 times. This would result it 1,000,000 polygons that all take up space in memory.
However, if you pack the geo, then it references only 10,000 polys in memory, yet you can have 100 instances of that high poly geo.
So using the copy sop to pack, just locally packs the input of the copy sop, and the instance sop essentially loads whatever you are instancing as if it were a file.
Hopefully this helps?
@@mrbennelson yes thx! So it doesnt matter which way you use. Vex or copy to points/copytransform sop way
nope, I don't believe it should matter@@g8610g -- just middle mouse click on your node after the instance or copy sop and ensure it says something like "100 pack ed primitive" or "100 packed discs" and you should most likely be good -- I say most likely only because I can't 100% verify your scene, but that's the basic concept around packed geometry. :)
@@mrbennelson Hi I'm learning a lot from your videos! Thank you for the contents. I was also wondering how different it is from the copytopoint pack and instance. So you're saying it works almost the same way except the instance node takes a file format?
@@user-sl309jd90 yep, basically. You can instance geometry on the opposite input of the copytopoint node. In fact, you can actually copy n number of geometries to pack and instance onto points based on a name attribute.
For example, say you have 10 points and 3 different versions of a brick, if you assign each an s@name attribute "piece_0", "piece_1" or "piece_2" -- Then just plug in the 3 bricks to the other input, but make sure each brick also has a unique name matching those points i.e. "piece_0" ... "piece_2"
Check "pack and instance" and bam, you can then copy as many bricks as you want but it'll only reference the 3 bricks, as opposed to literally copying the polygons.
I hope that makes sense? Sorry for the novel.
Hey man, great tutorial, one question, if I want to render with Redshift, how would I go about creating the instances and such for it to work with RS? Thanks man
For that, you'd follow a similar approach here, one difference would be put each brick version in it's own object level sop, and then name your instance attribute on the points something like:
s@instance = /obj/brick_01 or to randomize the path, you could do something like:
s@instance = "/obj/brick_0" + itoa(int(fit01(rand(@ptnum),1,6)));
This would be the case if you had 5 sop level bricks, all labeled brick_01 to brick_05
So then from there you should be able to render the points in redshift as instance points, and they should point properly to the object level geo sops you have.
One last note, you'd need to make sure your bricks have Redshift materials, as opposed to Houdini Mantra materials.
--- I know this is brief, I potentially could have missed a slight step or two, just this was off the top of my head, but I hope it points you in the right direction!
@@mrbennelson thank you! I'll give it a try
for sure! Let me know if it doesn't work and I'll see if I can help troubleshoot with ya@@estebanvasco3172
@@mrbennelson thanks I really appreciate that! One more thing though, so what I'm looking to do with this is an RDB shot, but I understand these bricks are way too high res for that, right? I would really need to optimize them to do that I'm assuming
So the best approach for something like that would be to use proxy geo in your sim, and then transform the high res geo for final render.@@estebanvasco3172
To do this has a test, grab one high res brick geo, drop down a bound sop, so it turns it into a low res "proxy geo" of your brick. Use an assemble node, and check "pack geometry" -- then pipe that into your rbd sim, and simulate.
Grab the high res brick, pack it and make sure its name attribute is the same as the simmed low res brick and pipe it into a "transform pieces" node. Then pipe the rbd simmed low res brick into the second input and it should transform your high res brick exactly how the low res is simmed. (You may need to pipe in the first frame only of the sim into the 3rd input)
But yeah that's a gist of using a low res geo in sim, but then rendering with the high res geo.
I wish you could do a course on VEX!
here's my money ; D
you know I hear that a lot -- I really need to do that. I want to help teach but of course gotta get some funding to do so. Eventually I want to launch some consistent, paid content that is worth the purchase. That's easier said than done though, I'm working on it!
Quick question -- would you prefer long form courses that are like 4 hours long or just like bit size 10 - 20 minute videos that are cheaper to buy? I've been toying with what sort of content to offer and having feedback is valuable!
@@mrbennelson Oh, I understand, the funding is an issue alright. But one step at a time! Glad to hear you're moving to that direction, because your content will worth it, in my opinion.
The 4 hour long course distributed as a playlist of 10-20 min videos is much easier to go through. I don't mind both types as long there's consistency in learning.
I would take a longer course to grasp the foundational & intermediate things of VEX, for instance, and would look for shorter videos to learn more of advanced concepts.
Maybe, that's how it's usually done, hah.
Else, do catchy snippets for social media.
Anyways, I find your style to be very cool. Many people might benefit from what you'll make!
@@serjkirchano1931 nice! thanks for the feedback!