Thank you! I'm deep in the geometry node depths right now, but this definitely helped :)

This comment is to the creator of video as he was honest to tell why and how to use nodes but he did that only at the beginning and not explained why he connected a bunch of nodes together, so I want him to make a video on how to handle all these data connections between nodes and use it according to purpose to get the desired result.

This right here is the kind of content I like to see! Really good at explaning and not afraid of side quests lol. You've certainly saved me a headache on a bunch of stuff

They should include a link to this video in the official documentation,

I like R3F for being a very good way to make quicky scenes without all the hassle, but I also noticed that this type of simplicity is a drawback of it, I've known threejs and how it works and have been using it for work, in the project I started creating things pretty straightforward using R3F with the drei library (which is encouraged by R3F) and I found myself removing more and more R3F related components and moving back to threejs, right now the only thing left from the project that is R3F related is the <Canvas> component and mounting and unmounting some models that act as helpers (like the grid) depending on the settings. Overall, R3F does achieve exactly what it tries to accomplish but for larger scale projects you should probably go for better solution that avoids using React Three Fiber IMO. Anyways, great explanation and fun to watch, it certainly would have helped me when I started my work with R3F for sure.

@52:48 end of countdown timer 🐇 🕳️

@43:51 light bulb moment #2 reinforcing lightbulb moment #1

@18:05 might be the most 💡 moment of this entire, super helpful, geonodes lesson 🧮🧨🖤

This is absolutely fantastic! was stuck at the same for very long

Thank you for this video,answered so many questions in short time ❤❤❤

Brother you are a life saver. I am a react developer who was trying to learn react three fiber. Read r3f docs -> got confused -> started reading threejs docs -> got confused -> tried coding in r3f -> thought documentation is incomplete -> started reading blogs -> did more coding -> again got confused -> watched this video. Now I am happy some of my concept were cleared. Thank you so so much!!!!

So happy I took my flashlight with me. Really good video.

This is a great tutorial, thanks! one added advantage of the naming convention is that this way there's no confusion between three.js classes you might want to import and the native fiber elements.

THANK YOU SO MUCH

Ha. "Python Dev" 😂😂😂😂

Great explanation! Thanks.

Excellent!

that was very interesting. thanks🙏

Any tutorial on using LLM for free . The transformers approach isn't giving good output

Hi, I have been following your tutorials from long, they are great. I wanted to understand... 1. Which is more easy or beneficial creating things directly with Geometry nodes? or using Python scripts to make geometry nodes? 2. Can we create every geometry node with Python? or are there limitations? It yes, then isn't it better to create Geometry nodes directly? as they as visual way of programming? Rather that coding them in Python and then using them? I really wanted to understand if Python based Geometry nodes helps something extra... I tried to search answers on internet but in vein. Thank you.

R3F rotation can be done with just "autorotate" on a drei orbitcontrols. which is much faster ^^

Thank you, I love your way of thinking. Very factual and not tribal. Its easy to get into tribal opion wars on things like these.

With a heavy CompSci / Math background, I found this to deliver CRAZY VALUE ❤ in terms of knowledged gained. You touched on the data structures, algorithms, Web API's, JavaScript ecosystem trends, and most importantly, the fundamentals of text embeddings and modern trends around their usage and deployment in an approachable, hands-on manner. 🤯 I'm always on KZbin, but literally had to look for where I could comment -- this might be my 3rd ever... Fantastic work 👏 🎉

amazing!

from making stitches to try to conditionally hide an input box based on another checkbox, no, no, no, the hole is not deep enough. go crazier. :p

51:03 Is Flip Faces node necessary? If someone wonders why not just join Curve Mesh on its own instead of adding Flip Face step, then consider that without this node Face Orientation would be wrong.

you're awesome like a LLM.

I just want to come by and say that you are probably the SINGLE BEST TEACHER on KZbin for me. I think you are the best for my specific learning style (which is also detail-oriented/rabbit hole/curiosity driven). Thank you for taking the time to produce those amazing videos, you sure have a fan club of yours!

27:50 : Bro started counting from 0 , what a legend and a true engineer

loved watching this!

Clip please!🙏

JavaScript cowboys

I just have one question about your choice of using JavaScript over Python: how dare you?

pretty useful!

best tutorial i have ever watched u are a genius ty!

Фашисты! Когда их приговорят к ссертной казне я первый вызовусь привести приговор в исполнение!

Sir, Thank you 🫡. I have difficulty focusing to videos like this and I watched many tutorials before and often got bored & ended up closing it. But your explanation was so good and I enjoy learning from you. Thank you for sharing your knowledge to us God bless you sir! I wished I discovered you earlier when I was still on college last year, my capstone project could've been different.

Beautiful video sir

Actually genius format of explaination.

An excellent comparison of embedding tools! Another free option worth exploring is Hugging Face's Transformers, which offers robust embedding qualifications. #AIEmbeddings #HuggingFace

this video in particular was really helpful! very crisp explanations. the flow of the video was really natural and well-paced. thanks man!

Thankyou for such an informative video. Liked and Subbed.

I rarely comment but your video is amazing and explains incredibly well how amazing geometry nodes are. I truly wanna thank you for this.

Incredibly helpful. Thank you my guy

Incredibly well explained! I'm glad I found this as my introduction to geometry nodes. I'm still a total beginner with Blender, but I'm amazed at what it can do.

greg, this is an extremely valuable video, i find it really useful. you truly dive deep into the holes and present the findings so clearly and elegantly. as a severe RHS patient myself, i salute you, greg, thank you.

Some pointers with displacement, bump, and normal maps. Displacement: Can be height field (like a bump map) or a vector displacement map, which connects to the material output. So all shaders will be affected by it. You don't *have* to use true microdisplacement to use it (there is a setting for bump only), but I would recommend it; if the height field texture map is to be used as a bump map, you can use microdisplacement to find the ideal displacement height and use that as bump distance (bump effect always 1). Bump maps: Can only be a height field map, but the result is plugged into individual shaders instead of on the material level, so you can have a bumpy substrate with a smooth topcoat, impossible with displacement without additional model for the smooth part. Ideally you should only use Bump Strength 1 and adjust Bump Distance (or the height input) instead to obtain ground truth normals that reflects what a displacement would do. Adjusting Bump Strength below 1 tend to introduce some weird clipping of the input. Bump maps requires on the fly *CALCULATIONS* of the new normals, something a normal map provides by simple lookup. Because of that, it is scale dependent. More on that below. Bump maps require no UV layout and less prone to brake (i.e. box mapping), are way more flexible to mix and match, and using the microdisplacement trick (above) you can find out the distance to use or spot if there is any math functions that break down easily. Bump maps are best used for small details because stepping issues will be less visible, but does add computing time. Normal maps: These provide the normal offsets by simply looking up the color. However, to work properly these require a UV layout, are tricky as hell to mix and match (correctly), and can be prone to errors (box mapping). The angles in a normal map are *NOT* affected by texture density, as the color lookup remains the same. It's as if it's the height of the mountain was automatically reduced to maintain the angles, compared to the bump map where the height is maintained (producing steeper angles). Make a triangle wave and array it. Scale on all axis gives you what normal maps do. Scale on x axis only give you want bump maps do (without accounting for it, anyway). Normal maps are preferred by game engines, since angles don't have to be computed (by the bump map slopes) and thus impact performance less. They are also better used for large details like large chamfers since it's done with a single color indicating that angle instead of a gradient. Which means you typically get away with smaller maps and 8 bit (per channel) instead of large 16/32 bit floating point maps to handle gradients (if stepping is a problem) for bump maps.

Note that under object data properties there is a texture space tab. Using generated (and/or object) texture coordinates you can adjust the position and size of the bounding box that is used. If using XYZ tangents for anisotropic shading and it looks off from what you'd expect, chances are the texture space has been automatically updated to something less than ideal. Generated will use 0-1 in XYZ for the bounding box, whereas Object will use origo and allow negative coordinates in unclamped space. The old modulo math function was prone to breaking with negative numbers, so had to account for that, whereas the new (truncated?) fixes those issues. Generated also accounts for some modifiers like bending. Object coordinates are great for box mapped objects, but we have to adjust the coordinate orientation to change how the mapping aligns, as there are no way to rotate the coordinate system with nodes prior to be used for the image texture node.

Use case for strings I'm constantly using, is showing a bunch of information related to the object. I'm working with blended projectors and LCD/LED video walls, and some of the information I show are: Aspect ratio, overlap (pixels, projectors only), individual image resolution (per cabinet), total resolution (per video wall), calculated pixel density/size (to determine readability), lens shift and throw calculations (within physical limitations?), and what projector screen is being utilized (may vary with size due to production limitations). Snapshots of this is then used internally to discuss around the solution, and maybe sent to gfx to prepare pixel perfect content to be used in the final renderings (although I use UV vector snap to force anything pixel perfect anyway). Sometimes things are used for communication purposes rather than rendering. One problem is since having to use nodes for separators, concatenations, and special characters, it can get really messy really fast, so all this is dropped into a separate node group. I wish there was a more elegant way of doing this using a multiline expression interpreter.

the yv map node works correctly when baking?