Video

Glad you found the video helpful! My understanding is that WebGPU has it's own shading language (it's called WGSL I think?), where as many different frameworks use GLSL (WebGL, OpenGL, Vulkan), which is why I focussed on GLSL here. I guess if you're explicitly wanting to make high-performance stuff for the web, then it would make sense to learn WebGPU. I haven't had a proper look at WebGPU yet, but I would imagine a lot of the core concepts would translate over, just with a slightly different syntax? Let me know how you get on!

Good shout! I've only recently come across RenderDoc, but it should be very helpful in the future!

Hi! Sounds like a fun project! My first thought would probably be to create a class which would handle a single set of tentacles, called something like TentacleManager (or maybe octopus? ha!). Each instance of the manager class would have it's own set of points, so one tentacle burst finishing doesn't interfere with any other. You would then have a global array of the managers, instead of single points, and when a manager has finished (you'll need some function on the manager to check for this!), you can remove it from the array of managers. And when you click, you can adda a new manager! I hope that makes sense, let me know if you've got any questions!

Sounds really interesting, I'd love to see some examples! (might be easiest to share in my discord?) Using 3D noise for flow fields seems like a really interesting idea, might have to explore that! Thanks for the comment!

@@BarneyCodes hey barney, the only examples i found where: czcams.com/video/PHySrgK7sj0/video.htmlfeature=shared And a demo of "generative garden" channel By 3D i meant using time to change the flow fields angles, i saw it on a video about "steering behaviours" of the coding train.

Haha yea they can take a bit of time but I think they help get the point across better than my words would on their own! (Hopefully!)

This is a great question, and I don't actually know the answer! I've never tried using a gif in P5js. I'd encourage you to try it out and see how you go (and report back afterwards because I'm curious!!)

Absolutely, it's actually the double slit experiment but the slits are so small you can't see them hahaha

No worries at all!

I chose JS so that people can just run the examples in their browser without having to download anything or set any environments up! But the CPU language choice is pretty much irrelevant because the GPU code (which is the main topic of the video) will be the same whether you're using JS, C, Java, C++ or whatever else you want! Definitely use whatever is most comfortable for you!

Great point! Older versions of WebGL/GLSL ES don't support bitwise operations so it slipped my mind, but if you're using a version that supports them, they are incredibly powerful! Thanks for the comment :)

@@BarneyCodes np, great video! You're doing the god's work with these videos. There's unbelievably small amount of content on graphics programming for beginners

Thanks so much, I really appreciate it! I'm trying to fill that gap as best I can haha

Hi! So glad to hear you're giving P5 a go, it's a lot of fun! And this is a great question! If you want to do anything with rainbow colours, your best bet is to probably use the HSB colour mode (p5js.org/reference/#/p5/colorMode). You're probably familiar with the RGB colour mode, where you specify how much Red, Green, and Blue you want in a pixel, but that makes it very hard to cycle through the rainbow. HSB stands for Hue, Saturation, and Brightness. Saturation is how much colour is present (no saturation will be greyscale, full saturation will be coloured) and brightness is how dark/light the colour is. The magic happens with the hue value, which dictates which colour you want, so if you increment the hue value you will get all the colours of the rainbow! So once you've got P5 running in HSB colour mode, you'll be able to set the colour of the particle just before it's drawn in the draw() function, just before the point(p.x, p.y) line. Since it's drawn using the point function, you'll want to use the stroke function to set the colour, using a hue, saturation and brightness value. To get started, you could try using the particles x coordinate to set the hue (you might want to look at the map function for an easy way to do this! p5js.org/reference/#/p5/map), but once you've got that figured out, you can use whatever you want to choose the position in the rainbow! I hope that helps, and I hope you have heaps of fun on your P5 journey! If you've got any more questions, please don't hesitate to ask!

@@BarneyCodes thank you so much for the reply! i'll be sure to check this out!

Glad you've found it helpful so far! I think I glossed over that in the video a bit. Basically the position value is being set in the vertex shader and is then passed through to the fragment shader (this is why the variable name in the vertex and fragment shaders have to match, because they're being used to pass the value across!) When sending geometry to the GPU to render, you have to specify the position of the vertices, but you can also specify the "UV" coordinates, which are basically the coordinates you'd like that vertex to use when looking up a texture, and this is the value I'm using to set the position variable in the vertex shader. How you set the UV coordinates from your CPU code will depend on what environment you're using, for P5js, they're set automatically! Since the UV/texture coordinate is per vertex, they get set as an attribute, which is only available in the vertex shader, which is why we need to set up the varying variable to pass the value into the fragment shader. I hope that makes sense, it's a bit of a rambling answer! If you've got any follow up questions, please just ask :)

It still amazes me too! Not sure how practical it is given how good 3D graphics are these days though hahaha

@@BarneyCodes even if it's just used as a showcase project it's still massively impressive

Thanks so much! :)

That's great! Glad you found it useful!

This video is more about writing shaders themselves, not setting up the environment to run them in (The GLSL code running on the GPU will be the same whether the CPU is running WebGL in JS or OpenGL in C!). I chose to use WebGL and JS because it's really easy to share with people online and lets people try it out without having to set up a local dev environment just to run some example code. If you do want to use OpenGL and C, there are many tutorials online that will teach you how to set that up, and then you can watch the rest of this video to learn how to write the shaders you'll need I hope that helps!

No problem, glad you found it useful!

Thank you! I think L systems are awesome, but there really doesn't seem to be much out there beyond the basics. Definitely something I'd like to keep working on in the future!

Thanks so much!

This is true! But as I found out, each colour channel only gets 1 byte of data (256 values), so you can't get much precision out of them, which is what was causing the weird speckles! I tried to get around this by using all 4 bytes of the colour channel to store the value, to give more precision but turns out I did it in a silly way haha There are methods for setting up textures to use the channels in different ways, but P5js doesn't really expose these to the user. Definitely worth looking into if you're interested though!

Thanks so much, that's very kind! At the moment I'm focusing more on development than filming but I definitely plan on doing more like this in the future! Thanks again for the comment :)

Thanks for catching that! I've hopefully fixed that up now :)

If you're just getting started with it, you really can't beat Dan Shiffman's videos here on CZcams (the channel is called 'The Coding Train'), he's got heaps of videos on using Processing so it's an excellent place to start. Otherwise, the documentation is decent enough that you can probably just download Processing and start messing around and figure a lot of it out!

I think my first ever video on this channel did something similar to this. The general idea is the same, where the proximity to the mouse influences a particle, but instead of having a "home" position that the particle is trying to reach, they just have a velocity that they use to move around. The velocity can then just be pushed in a direction away from the mouse if the particle gets too close. Hope that helps!

Thanks so much, glad you found it useful!

This is a really great question! I think I forgot to include this in the video, but shaders are only as fast as the slowest case, which is probably a bit different from how you're used to things working on the CPU! On the CPU, since things are happening one after the other, if you can move on quickly to the next iteration you can save time overall. However on the GPU, because all the pixels are being calculated at the same time, the shader has to wait for all the pixels to finish before it can finalise the result, meaning that even if 99% of the cases break early, the shader still has to wait for the pixels that are in that final 1% that are taking their time! I don't think the optimisation you've suggested would hurt the performance at all, but it's better to focus on speeding up the worst case, rather than speeding up the most cases (which can take a bit of getting used to!) Hope that helps clear things up a bit, let me know if you have any more questions :)

@@BarneyCodes Thanks for the answer, and thanks for the video! I still have one more question if you don't mind: You say "All the pixels are being calculated at the same time", so I'm trying to get a grasp of how gpu's do this. Say the gpu has 1000 cores. If a scene has a million pixels, each core would still have to do multiple pixels each. Can these calculations be parallel within one core, or does each core calculate "sequentially"? Because if they at some point have to do sequential calculations, then I feel like there should be a benefit to optimizing by breaking, as that core could then process more pixels. So I guess the question is if each core utilizes some internal parallelization technique, or if one core can only handle one calculation at a time?

You know what, I don't actually know! I've read that they're all done at the same time before, but hadn't stopped to actually think how that would work in practice. I just did a bit of googling and it looks like each core can run multiple threads at once (each thread calculating a single pixel), but it's still not enough to actually do "all the pixels at the same time"! From what I've read the GPU executes a block of pixels at the same time, and only moves to the next block only if EVERY pixel in the first block has finished, so it's kind of a mix of what we were both saying! With my example code though, it's pretty likely that a lot of the blocks would be able to finish early, so your optimisation would definitely have an impact. I think it depends a lot on what you're actually doing in the shader and it wouldn't be quite as significant as the same optimisation on the CPU. Thanks again for the great question, I learned some new stuff, and hopefully that helps you as well!

@@BarneyCodes I see, thanks again for the reply!

Thank you so much! Glad you found it helpful!

I definitely think this is the way to do it but, unfortunately, I don't think my current implementation is fast enough to handle multiple rays per pixel. I think the mip-map optimisation I covered in my last video would probably allow me to do that though so I'll look into it again when I make the move over to Godot Thanks for the comment!

That could be a lot of fun and probably not too difficult to get working! Cheers for the comment :)

You're definitely right! At the moment it's just a linear interpolation based on the angle of the sun so not very accurate at all! Thanks for the suggestion!

I haven't heard of voxel space engines before but they sound cool, I'll have to check them out. Thanks for the comment :)

I was thinking along the same lines, it would be great to actually use the sunlight/shadow system as part of the gameplay and I think solar panels would be a great way to do that! I'll have to see about simulating wind as well, might be a bit more complex to figure out how wind would flow around the island! Thanks for the comment!

What issues are you running into? There are definitely some differences in getting the environment set up, but the actual shader code should be usable between both (you might just need to check what uniforms/attributes are available by default in Processing vs P5js) If you're getting any error in particular I can try to give you a hand to get it sorted out!

@@BarneyCodes That's what I thought as well. When I first copied everything down the shaders just refused to compile, so I figured the names of the attributes must just be different. It took me a while to find any documentation about what attributes were available in the Processing environment (the official site has pretty much nothing that I could find about implementing shader functionality despite this being a feature for years at this point) vs P5, but eventually I found examples in an old backup of a blog that went pretty in depth about how this stuff worked for Processing. After replacing all of the attributes with their correct counterparts the shaders were finally able to compile and run, but specifically the vertex shader just doesn't have the expected behaviour. It refuses to shade anything in 2d that isn't a square that fills the whole screen. I've been tinkering with it off and on for a while trying to figure out what in the implementation is different enough to make this not work, but I don't have enough experience or documentation support to really know what's up here

I've only used shaders in Processing for full screen effects, so unfortunately can't be too much help there sorry! A few of the example Processing shaders I've seen have different defines at the top, eg: #define PROCESSING_TEXTURE_SHADER or #define PROCESSING_COLOR_SHADER maybe something like that helps? I know Processing also lets you either supply a vertex shader or just use their default one, not sure which route you've been going down (maybe both already!) but it could be good to try them both out to see if that helps at all. As a last resort, the Processing source code is all available on GitHub so you can also dive into that (if you're feeling brave enough!) to try and figure out what's going on and why it might be behaving strangely! Sorry I don't have a more concrete bit of advice for you, but hopefully there's something in there that's helpful? Good luck!

Interesting idea, I like it! I really like the idea of using solar power because it would work nicely with the sun/shadow system and I could somewhat accurately simulate the efficiency of the panels changing throughout the day, taking into account shadows and what not. Thanks for the comment!