Get 20% Off + Free International Shipping with promo code ACEROLA at mnscpd.com/acerola ! #ad As I announced at the end of the video, I am now a full time content creator! Expect videos to come out a little bit quicker with higher quality and less compromises on the project itself (I kinda bit off more than I could chew with this video lol). For a more in depth announcement check out my tweet: twitter.com/Acerola_t/status/1657244847068315648 I'll also be starting up a real stream schedule, I really mean it this time! I'll be streaming monday/tuesday/thursday over on twitch (linked in description). I'll be streaming whatever I want so it'll probably be variety with intermittent dev streams when I feel like it. I'd really appreciate it if you stopped by! Twitch partner is pretty much my last goal in life. Thank you so much again for all your support.
Some thoughts about the voxel placement: 1. Their examples for enclosed spaces might indicate that they don't limit the flood fill by a radius but by the total number of filled voxels. That would make sense physically since the contents of the grenade expand to a near-constant volume (assuming constant external pressure) 2. Depending on the representation that the physics engine uses (for example bsp or octrees), real time collisions between voxel grids and the environment might not be too expensive. 3. That would make it possible to use smaller local voxel grids around the grenades instead of a global one which saves a lot of memory.
@@Sylvarus I think they might bake the environment in chunks, and the chunks that contain dynamical objects will have several variations corresponding for different states of the objects
if source 2 is still quake engine under the hood, it might still used baked-in collision hulls, and there's not that much dynamic stuff which might need checking - until I see the smoke interacting with moving doors in interesting ways my bet would be they take the easiest possible way out there : p
@@potatofuryy source 2 authoring tools don't use collision brushes anymore. collision brushes are nevertheless very efficient for static geometry, so they might bake all static collisions instead of considering them separate objects where possible.
I know that you are literally a professional at this stuff, but it still breaks my brain that you made all this plus the entire video in like a month or so. Absolutely nuts, makes my week when you drop a new vid!
@@EvokerKingAll joking aside a lot of people dont comprehend how hard of a tightrope walk remaking CS in a new engine is, any minor screw ups that affect the extremely refined gameplay loop will get more hate than most Triple A devs get for releasing absolute trash. To just make a CS game in source 2 isnt that hard, to make one that keeps the high skill mechanics identical while upgrading everything else and making sure none of it screws with said high skill mechanics thats where the challenge lies. Not to mention they had to make sure it was also extremely optimised and ran on a potato while looking nice.
every once in a while i am forcefully reminded that the number of operations per second current generation hardware is capable of executing is absolutely fucking bonkers bananas
Acerola, could that red hole texture be a parallax effect? They just use it as a mask? That might be doable? If it's skewed at an angle, they probably assume you can't see through the hole anyways, so they just hide the mask all together (due to parallax's weirdness at acute angles?)
Yeah i think he gathered that much, he said he was confused specifically about how they use this mask for other players at different viewing angles than the shooter.
6:01 I literally exclaimed "RAY MARCHING" at this exact moment lol. I like how you structure those videos, you don't just deliver information, you make the viewer arrive at the conclusion themselves, that's how you actually teach people stuff.
personally i would have coded the smoke to have a set amount of voxels to expand, counting down from the total every time one is placed, completely ignoring the radius. this way you get smoke that entirely fills a corridor that is longer than the free standing smoke radius. though if you do this the elliptical nature of the voxel cloud is lost so valve must be doing something else as well, probably a combination of the two
you could modify the floodfill algorithm to not expand vertically (making it think its blocked) every x frames which would act as a sort of atmospheric pressure assuming it happens quick enough not to create artefacts. Or put some sort of chance element on vertical expansion
I think that (and more) is perfectly feasible if you calculate the voxel fill on the CPU and just upload the thing into a compute buffer. Considering its not a huge amount of data, I think it's perfectly feasible.
Why don't you just use horizontal and vertical components for the counting function. Setting the vertical count limit smaller could create the ellipse shape.
Just a quick thought on the bullet hole mistery: My first thougth (with the texture and all) was that they might be using a mask. Basically, there is a seperate render buffer that renders two quads with the texture you showed for the entry and exit "hole". These get combined mutiplicatively so you only get a non-zero value if the entry and exit overlap (which means you should be able to see through in a straight line). Then the inverse of that result is used as a mask for the generated smoke texture. This might work... or not, i don't know just my two cents on the topic. P.S.: Great video as always, loved the PsychoPass-Reference.
Would be a good idea, but in the video he explicitly said he wanted it to work from multiple perspectives (not sure if that's how it works in CS2). Though I have another idea that would greatly simplify the calculations (and most importantly eliminate multiple checks and sqrts): They could compared each position to be sampled with each ray, with X and Y being the offset in the plane, and Z being the distance along the ray. Then they could sample the texture using X and Y, and compare the sampled value with Z to see if the voxel should be rendered or clipped. This is super simple since the texture sampling can be set up to clamp out-of-bounds samplings, and the texture also provide the hole shape, eliminating the sqrts. So all we would be left with is a few multiplications, two divisions (scaling distance to the texture bounds), a texture sample, and a single comparision with division between sampled value and Z (to check whether the voxel clipped).
I think that the way that texture works is it is actually just a map that is used to alter the density of voxels that the bullet ray passes through (in screenspace relative to the intersection point with the ray). Purely a speculation on my part though, I only really have a surface level understanding of 3d graphics.
My favorite mystery I'm the whole puzzle. My story is a modeler told them to subdivide those voxels and they said, how big and how fast is the projectile.
@@vocassenpretty much my solution as well, if I'm following you right, though I added a step to animate the effect and increase the granularity of edge activity around the time/speed and space where a projectile would cavitate in line with its bullet physics model on the engine... Cool stuff.
I wrote some volumetric clouds a awhile back and on the topic of curl noise: consider bitangent noise instead. The main feature you want from curl noise is the zero divergence aspect, and you can get there in two gradients instead of three so it's cheaper if you're generating it in realtime, which is worth doing for your zero-divergence component
I'm a bit disappointed; I was like "who's dani" and thought he'd be the absolut dev professional with knowledge equal to black magic, but realized his contribution in your analogy is the presenting style instead
I'm astounded by this video. In like half-n-hour you explained 3D coordinate systems, noise, ray marching, several properties of light, BAKING, a fill pattern that's re-usable within the effect, plus five or so other prosperities on top of almost replicating the smoke effect. Pretty amazing you did this in less then a month tbh. 13:00 Now wondering how in the world Teardown's lighting is so good. Since all their level geometry is dynamic, they can't really bake anything right? 🤔
Math buffs and programmers must have some form of insanity to think like this. I get what's going on in a simple way, but to keep track of all of these functions and then stick them together in a functional way is simply astounding. What's more is that they've figured out how to make this stuff get calculated quickly. This is why I try to never give game devs crap when they do silly stupid things that break stuff. They've already achieved feats that I can't even begin to touch.
Well, to be fair, we didn't figure out how to make this stuff get calculated quickly. That's the GPU and whoever designed that already figured it out for us. We just figure, "Hey, if we do this thing 36000 * 800 times, it'll be slow. Let's try to reduce those numbers." :)
I'm not an expert at all, but the bullet holes look like 2d composites on the final alpha matte, and if you move away from the line of the bullet another duplicate of the texture slides to obscure the hole.
Another small thing about the bullet holes is that they react to the volume of the smoke. You can only create bullet holes near the edges, not in the middle (you might able to with continued shooting in the same place, not sure about that). This was hugely impressive though. Great video!
I'm currently ~2 weeks into a psychotic speedrun attempt at teaching myself how to make a halfway decent game from scratch so I can finally properly tell this visual narrative I've been mulling over for a few years, now that the message and themes of it feel super relevant to current events. Still sleep deprived from beating my head against shader code all weekend and been kinda feeling like none of it even really sunk in, but... for the first time, I actually feel like I kinda understood most/all of this. Normally your more technical videos tend to lose me early in, after which I'd only occasionally continue watching for the top notch presentation and entertainment value... guess I have some older videos to re-watch :p
Could the bullet hole textures Valve used on the smoke have been used as perimeters for real-time textures? Like the flat textures on the portals in Portal made to look like the actual environment through the portal. And each perspective from each player in the lobby could be rendered separately, like the multiplayer in Portal 2. Just a thought.
I believe that is the case, but this alone doesn't explain the 3d effect. In CS2, when doing the depth testing through a bullet hole, each pixel takes from a seemingly correct position of the noise, creating a proper 3d effect: The smoke inside fades into the surface of the smoke. This leaves me to believe the ENTIRE voxel is ignored when it sees the bullet hole.
I do wonder if they have a global voxel grid, or if they make a local one when the grenade deploys. If you included simplified bounding boxes for your environment objects (which they might already have for basic collisions), it seems like the cost of setting it up might low enough.
Obviously the result is astonishing, a lot of work have been put into that! But I really admire the effort your have put into the explanation of the animation parts, that is soooo fascinating to watch... Thank you for that :)
Me: F*king amazed by the work and the results. Acerola OCD: What? Still not enough? Me: I never say that Acerola OCD: Fine I'll simulate how light pass through particles differently
For the bullet holes, I would've just thought they projected the texture through the smoke. Keep track of every bullet hole's location and direction, then when sampling the smoke density you project the point you're sampling onto that plane and sample the texture that way. To make the hole get smaller further from where it was shot, you can offset the vector along which that point is projected. I'm honestly not sure how efficient that is - I'd have to try it - but that was my first thought when I saw how the smoke works in CS2
It'll be interesting to see the bugs we get with CS2's smoke, beyond what people have already tried there isn't much else that will give us so much raw information to speculate over. Keep an eye out for smoke bug videos folks, that's all I'm saying.
I always love seeing your anime and manga references to the Monogatari series, Tatami Galaxy and more. But I really didn't expect a reference to god from Oyasumi Punpun at 3:45. Keep them references coming
I believe that the smoke hole could be a displacement mask that hides that part of the smoke, much like displacement decals but far more sophisticated, still confusing and amazed how it is done and how you managed to get close to the real thing.
Idea for the texture they use for the holes. Maybe it is used similar to a volume texture in 3d by just scaling the height of the texture a lot into the volume and then they subtract it from the density. Like a 3d decal. Or they remove the voxels on hitting them. that would work with the grenade explosion aswell.
Rather than removing the voxels I think the texture is just used to negate the visual effects already induced by the smoke. Like, "if bullet hole texture shows black, do not show smoke effects here". Then fade that mask out over time with some function to give the smoke the appearance of refilling the smoke, when really it was still there the entire time.
I was going to give my opinion on how the decal texture might be used but I will instead respect your wishes and keep it to myself. I will also be implementing my idea in my own free time to prove thats how it works. I hope you look forward to it.
Bro, this is incredible. As an armature myself my solution would have been to use a low res volumetric particle emitter with a set radius and have the particles kill themselves on any collision lmao
Just extrude that bullet hole mask along the bullet vector, you get a irregular 3d shape with density. Take that into account when you do raymarching, you get a hole in the volume. It's probably the reason why the hole only appears for a very short time, because the more holes you got, the worse the performance.
this made me realize some extra reason to have smoke as voxels: replays. Being a competitive element, making the smoke visible in replay (and tournament transmissions probably also more important in this day and age) exactly as as played is fundamental
Wouldn't it be possible to deside the shape of the smoke by throwing particles and and then calculating witch voxel a particle is in and then and filling in the voxel. (And I mean throwing like 50 particles not just making particle effect smoke, so not rendering the particles themselves) That way you don't actually have to pre-bake the whole map. It also gives you the posiblility to make the smoke Dender if multiple particles are in the same voxel. You could also only make a voxel grid at the moment the smoke is thrown and only in a certain range of where the smoke lands. And only keep that grid for a the life span of a smoke grenade. That way you minimize the amount of voxels that need to be rendered. You would still have to make sure that shit dousnt break when multiple smoke grenades are thrown.
This smoke reminds me very much of the clouds and / or fog seen in Xenoblade Chronicles 2 & 3 and The Legend of Zelda: Tears of the Kingdom. Maybe Monolith Soft, who worked on both games, used a similar technique for nearby fog / clouds in their games.
The bullet mask is probably just projected on the smoke volume from the direction of the bullet. It's just used to subtract density. This should work for all viewers. Imagine a negative projector for the density. Should be easy to give you projected coordinate of a world space point on the bullet mask, and it will form the nice cone. The resolution would be very high as the check can be done in view space not voxel space.
This prevent bullet interactions from two directions, no? If you shoot from left and someone shoots from right, you wouldn't see the right-left bullet hole inside the front-back bullethole.
I have no idea what you are talking about, but I love it so much. It would be cool to understand everything, but I also have fun just looking a the complexity of these examples. Thanks for the awesome videos!
Very well made video. As a fellow graphics programmer, its nice to see some love for topics like this. Kept me entertained throughout the entire video too. You've earned a sub
Congrats on being a full time funny internet man. Your videos are what keeps me inspired in pursuing a career in computer graphics. It's so much fun to watch your content, thank you
The smoke looks so realistic in some screenshots. It looks like you went into photoshop and cut out an image of dust, and then you just pasted it into a screenshot of a game.
Absolutely amazing explanations and showcase with an appropriate amount of humor. I hope you continue to do what makes you happy and share it with us all!
Some thoughts on the bullet hole thing; it doesn't look like Valve does proper shading or "tunneling through" the volume either. I suspect that texture is used to simply mask the entire volume before compositing it into the scene. The "black magic" is only a matter of how to place, blend and track the location and "angle" of the hole particle. Though the holes only last a few frames so it's okay if the solution isn't very precise. This approach wouldn't work for bullet holes that don't closely match the camera perspective - but if you think about it, it doesn't have to since you don't see those anyway.
I remember hearing Breath of the Wild rendering everything under the water surface at half resolution, but it would then later be changed by a displacement map. I think the smoke effect gets away with the low resolution just fine as is, but I wonder if a similar process might still be able to fake extra detail.
For your question about how they did the bullet holes: It seems like a depthtexture/stamp/decal that is placed on the volume's bounds mesh (the two boxes you show at 5:05 ) while its projected along the camera vector through the volume till it hits the end of the volume (the backside). This would be a cheap way where you can sample the normalized depth into the volume and compare that to the depth of that bullethole, if its a higher value then the texture, you just sample 0 for density, otherwise you sample the voxel's value. :) Also on the approach to voxels you described: I think it makes more sense for the voxels to be aligned to the bounds we see at 5:05 again instead of the bounds of the entire playable map. Even at a theoretical 256^3 (akin to a 4K texture at 16.8 million pixels). that wouldnt be practical memory wise (especially given the low target platform of CSGO 2). They may use something like depth cubemap captures or some other approach to querying the environment (Maybe collision meshes as they are pretty cheap? though they mostly live on the CPU not the GPU). All in all great video! love the details you went into to explain the implementation!
@@Acerola_t The decal would be more of a implicit/virtual decal. In shader its placed and oriented on the bounding box mesh face closest to you (akin to splatting it, but more focussed placement where the bullet travels through). The depth at 1 (white) means it's the closest point and the depth at 0 (black) is the furthest point (other side of the bounds mesh). Something like a virtual/Distance field/implicit plane would do the trick and be cheap as well.
@@benshulz4179 Yeah, you basically do boolean type operation this way. It does become more expensive with more bullet holes though, so you'd have to be careful there.
Incredible video, I will try this out myself, seems fun! Meanwhile, a theory on the bullet holes: When you shoot, it applies the smoke bullet hole decal (and decreases it's size over time) on EVERY voxel on the shot's path, including the voxels inside the smoke. Then, when doing depth test for a pixel, we check if the pixel can see a decal from a voxel. If it can, it ignores that entire voxel for depth testing. So if we see all voxel's decals, we ignore all voxel's depth and see through smoke, in that pixel. But if we see two voxel's decals, we ignore only those two voxels' depth. After applying noise, it should create a proper 3d bullet hole effect. Explosion clearing might be the key here. It could in theory just mark voxels as "do not render" and then apply a smoothed explosion decal on every voxel which is touching those "do not render" voxels, then ignoring entire voxel per-pixel like above if the decal is seen.
Could use sparse octrees to dramatically increase resolution while maintaining performance however that does seem like it would be quite difficult to pull of on the gpu
I think they use marching cubes, mip map of a only one hole texture setting the angle on creating, and apply based on voxel of entry and position of bullet. After they use the entry and out of bullet to interpolate the animation.
I have done this last year in my scratch(yes scratch 3d game) I basically made a lot of game object with collisions and used a lot of raycasts to find where hole in smoke was
You are my favorite gamedev youtuber and you actually inspired me to start learning a little bit of gamedev with your grass video (god that grass looks good), so I am very exited that you are going full-time and I hope it works out well for you!
An idea on how Valve could be creating the holes is by using the bullet hole texture as a mask on the player perspective for the ray-marching to continue through the smoke. The mask is centered on the bullet hole and allows rays from the player perspective to avoid the marching early-stop. The size of the hole could when opening/closing could be the hole texture being scaled up/down using some non-linear function.
I love these videos! Seeing the smoke just getting small little improvements along the way and summing up to something that looks amazing in the end is like a story on it's own!
i think the answer to the bullet hole question is that they have a wholly separate system than the one you made, with a bunch of smoke and mirrors instead of it being straight volumetric rendering. the way that the smoke would intersect and wrap around map geometry would use voxels and similar math as your model, but use a different rendering system. if the voxels they spawned in the devvlog are just particles with a cube mesh in a voxel-like pattern and a world orientation, they can substitute the cube mesh with a typical sprite stack, render it facing client cameras, fill in the gaps with some function that uses actual volumetric clouds that only generates clouds off of a heightmap of existing sprites. raycast intersects sprites, overlay bullet hole texture in a volumetric heightmap at the location of the sprite's equivalent of a face normal, each sprite card in the stack receives decreasingly mipmapped bullet hole texture overlaid onto the height map, volumetric clouds receive a hole as a result because every single card in the sprite stack has the same heightmap adjustment. use the actual cloud to blend edges between sprite card.
I would love to see more similar stuff like voxel and volumetric fluids. I am quite a starting game dev and a tech enthusiast. I am currently having lot of fun understanding how even the quite complex programing and software works but rendering, especially realtime is something that I cannot find enough good materials, especially some interesting. And your videos are just that, by the way I have bought books from Invidia that you recommended in some older videos and they are really good thanks.
Thankfully it all kinda works the same for volumetrics, so if you read through the resources I put in the description I think you'll really accelerate towards what you want to do
very impressive how maths, coding work together to create beautiful visual graphics. Very good job bro I understood how these smokes are made in detail
it kinda looks like individual voxels are moving in the csgo version so they might be using some system where either voxels atthe edge of the smoke can be squished a bit to have a more precise edge or they're making a small local voxel grid for the grenade that moves in itself and is only as big as the smoke radius
This is really cool. While I'm not currently doing/learning game development, I love learning about the trucks that developers use to make perfomant and visually pleasing graphics. This is definitely something you excel at teaching and demonstrating at a good level of abstraction. It feels like you know just how much detail you have to share so that your videos are informative and engaging, while introducing topics/techniques that we could go research if we want more detail.
My guess on the CS2 specific holes is that they’re using some GPU buffer shenanigans, much like the Portals in Portal. How exactly they’d employ this strategy, I couldn’t tell you, but it’s my only good guess here.
Great job. I see many have tried to recreate this effect, but it seems you are the first to achieve a result that is so close to the original solution.
Educated guess on the bullet holes: An array of matrices that project the bullethole texture to an orthogonal "tunnel-projection". Sample the texture and mulitply to density. The problem here is of course this would mean one sample/bullet/step. So a few more wild guesses: They reduce the amount of voxels by not having the whole map considered for the live smoke, but only inside the bounds, so they have fewer live-voxels, but can add additional info about bullets saved in there. For example each voxel only contains indices to the 2-4 closest bullets in the array, so only 2-4 texture samples are needed, instead of ~10-50. Also I guess there is some prioritizations, for example preferring bulletholes parallel to the viewdirection before orthogonal ones, or middle lifetime before semi-appearing before disappearing. TLDR: - have dynamic voxels only in a limited area around the grenade - save all bullets in an array - prioritize bullets for each voxel, save the most importent bullets indices inside the voxel - density *= tex2D(_BulletMask, mul(_Bullets[currentVoxel.bullet], samplePosition));
Very interesting video, thanks for all this work! The progression of information is very well made, taking the audience to the relevant conclusions instead of simply dumping info
For the bullet holes, maybe the texture is used for how much smoke is removed by the bullet hole... I think all you have to do is figure out what part of a rectangular prism the point is in, translate that to the surface of a square that then is used to find the value of the bullet hole at that point, and then multiply or subtract the density you see at that point on the ray by the bullet hole texture at that point. Then you just need to either shrink the prism or change texture based on a timer. I probably have absolutely no idea what I am talking about.
As for how they did the bullet holes, could be that they compared each position to be sampled with each ray, with X and Y being the offset in the plane, and Z being the distance along the ray. Then they could sample the texture using X and Y, and compare the sampled value with Z to see if the voxel should be rendered or clipped. I do not know if that is necessary given that the noise already could provide for a good texture in the hole, but simplifying the SDF code from a cone to a cylinder sounds like a good start. Especially eliminating those ifs and sqrts would be top priority, which would be possible given the texture sampling would clamp out-of-bounds samplings, and the texture also providing the hole shape, not the sqrt. So all we would be left with is a few multiplications, two divisions (scaling distance to the texture bounds), a texture sample, and a single comparision with division between sampled value and Z (to check whether the voxel clipped).
It has been more than 1 year since the upload of the video but no one got "Bake monogatari" until now it seems. With your editing, memes, name of the channel . And with your dedicated shelf, I can say you are an avid fan. How cultured.
Some observations about the showcase video: 1. Bullets were always shot near the surface of the smoke (than the core). 2. Weird artifacts when grenade exploded on smoke. 3. No tube-ish shape when a bullet is shot through the smoke. So, they probably used a stencil buffer and the random bullet shot texture is the stencil? They didn't shoot near the core as it would give it away as a tube-ish shape would be expected.
The texture at 28:18 could just be used to modify the signed distance function. Imagine a sample taken in the signed distance function. It has world coordinates, you can convert this world coord into a distance and direction from a bullet’s path. Convert this direction into a vector that describes a 2d direction from the bullets path to the sample point when viewed along the bullet’s path. Finally starting at the centre of the sample image traverse outwards by distance * bulletPathToSampleDirection. Multiply the distance by a random value for each bullet, maybe rotate the sample image for each bullet as well, and boom now the bullet hole looks smokey instead of like a cylinder. Haven’t tested this idea, it might have flaws, but this is my guess on what they did there.
I think maybe the bullet hole texture could be a used as a mask that is wrapped around a half sphere very close to the smoke in order to enable it being viewed from all angles
@@Acerola_t I wanted to know if what I said would be correct outside of a vacuum, so I wrote some benchmarks. I'll edit this comment with the results when I'm confident that I didn't make any obvious mistakes.
Get 20% Off + Free International Shipping with promo code ACEROLA at mnscpd.com/acerola ! #ad
As I announced at the end of the video, I am now a full time content creator! Expect videos to come out a little bit quicker with higher quality and less compromises on the project itself (I kinda bit off more than I could chew with this video lol). For a more in depth announcement check out my tweet: twitter.com/Acerola_t/status/1657244847068315648
I'll also be starting up a real stream schedule, I really mean it this time! I'll be streaming monday/tuesday/thursday over on twitch (linked in description). I'll be streaming whatever I want so it'll probably be variety with intermittent dev streams when I feel like it. I'd really appreciate it if you stopped by! Twitch partner is pretty much my last goal in life.
Thank you so much again for all your support.
Can you try recreating tears of the kingdom's abilities? Seem like a cool thing to try to figure out
@@toolazytobeoriginal4587 he won't cause tears is just havok engine physics. There isn't much to recreate.
@@MaxIzrin Wdym? what did gilette do lol
Always a pleasure watching a new video of yours
@@MaxIzrin i knew it was gonna be transphobia
Some thoughts about the voxel placement:
1. Their examples for enclosed spaces might indicate that they don't limit the flood fill by a radius but by the total number of filled voxels. That would make sense physically since the contents of the grenade expand to a near-constant volume (assuming constant external pressure)
2. Depending on the representation that the physics engine uses (for example bsp or octrees), real time collisions between voxel grids and the environment might not be too expensive.
3. That would make it possible to use smaller local voxel grids around the grenades instead of a global one which saves a lot of memory.
Realtime collisions are required for CS because there are a few dynamic objects (doors/windows) that can be opened/destroyed.
@@Sylvarus I think they might bake the environment in chunks, and the chunks that contain dynamical objects will have several variations corresponding for different states of the objects
if source 2 is still quake engine under the hood, it might still used baked-in collision hulls, and there's not that much dynamic stuff which might need checking - until I see the smoke interacting with moving doors in interesting ways my bet would be they take the easiest possible way out there : p
@@user-sl6gn1ss8p Source two doesn’t use collision brushes anymore.
@@potatofuryy source 2 authoring tools don't use collision brushes anymore. collision brushes are nevertheless very efficient for static geometry, so they might bake all static collisions instead of considering them separate objects where possible.
I know that you are literally a professional at this stuff, but it still breaks my brain that you made all this plus the entire video in like a month or so. Absolutely nuts, makes my week when you drop a new vid!
While working full time!
And not putting an ad every 5 minutes like some people do !
he wasted no time searching for high resolution images for the memes
He’s far from professional. An amateur hobbyist at best.
@@cumibakar10 you call this amateur?
Wow, this took a lot of work.
True
took valve 10 years to make a second csgo, i now see why
@@EvokerKingAll joking aside a lot of people dont comprehend how hard of a tightrope walk remaking CS in a new engine is, any minor screw ups that affect the extremely refined gameplay loop will get more hate than most Triple A devs get for releasing absolute trash.
To just make a CS game in source 2 isnt that hard, to make one that keeps the high skill mechanics identical while upgrading everything else and making sure none of it screws with said high skill mechanics thats where the challenge lies.
Not to mention they had to make sure it was also extremely optimised and ran on a potato while looking nice.
It is work
It just works
every once in a while i am forcefully reminded that the number of operations per second current generation hardware is capable of executing is absolutely fucking bonkers bananas
Acerola, could that red hole texture be a parallax effect? They just use it as a mask? That might be doable? If it's skewed at an angle, they probably assume you can't see through the hole anyways, so they just hide the mask all together (due to parallax's weirdness at acute angles?)
Would make sense because they use parallax mapping for bullet decals as well, you might be onto something
Best point I've seen yet
This was my first thought too.
Essentially a decal texture that lets you see through the smoke when you are looking at it.
Yeah i think he gathered that much, he said he was confused specifically about how they use this mask for other players at different viewing angles than the shooter.
@@NoTengoIdeaGuey It should work the same way. If it's flipped 180 degrees, just use the same shader with a flipped direction.
6:01 I literally exclaimed "RAY MARCHING" at this exact moment lol. I like how you structure those videos, you don't just deliver information, you make the viewer arrive at the conclusion themselves, that's how you actually teach people stuff.
personally i would have coded the smoke to have a set amount of voxels to expand, counting down from the total every time one is placed, completely ignoring the radius. this way you get smoke that entirely fills a corridor that is longer than the free standing smoke radius. though if you do this the elliptical nature of the voxel cloud is lost so valve must be doing something else as well, probably a combination of the two
you could modify the floodfill algorithm to not expand vertically (making it think its blocked) every x frames which would act as a sort of atmospheric pressure assuming it happens quick enough not to create artefacts.
Or put some sort of chance element on vertical expansion
Yeah the more you try and solve this propagation issue to fill generic volumes the more you approach actual fluid simulation lmao so I kept it simple
I'm picking up that the more effort you put towards implementing it the more often you say "what the fuck, valve?"
I think that (and more) is perfectly feasible if you calculate the voxel fill on the CPU and just upload the thing into a compute buffer. Considering its not a huge amount of data, I think it's perfectly feasible.
Why don't you just use horizontal and vertical components for the counting function. Setting the vertical count limit smaller could create the ellipse shape.
Just a quick thought on the bullet hole mistery:
My first thougth (with the texture and all) was that they might be using a mask.
Basically, there is a seperate render buffer that renders two quads with the texture you showed for the entry and exit "hole".
These get combined mutiplicatively so you only get a non-zero value if the entry and exit overlap (which means you should be able to see through in a straight line).
Then the inverse of that result is used as a mask for the generated smoke texture.
This might work... or not, i don't know just my two cents on the topic.
P.S.:
Great video as always, loved the PsychoPass-Reference.
that's what I thought as well
Would be a good idea, but in the video he explicitly said he wanted it to work from multiple perspectives (not sure if that's how it works in CS2).
Though I have another idea that would greatly simplify the calculations (and most importantly eliminate multiple checks and sqrts):
They could compared each position to be sampled with each ray, with X and Y being the offset in the plane, and Z being the distance along the ray. Then they could sample the texture using X and Y, and compare the sampled value with Z to see if the voxel should be rendered or clipped. This is super simple since the texture sampling can be set up to clamp out-of-bounds samplings, and the texture also provide the hole shape, eliminating the sqrts.
So all we would be left with is a few multiplications, two divisions (scaling distance to the texture bounds), a texture sample, and a single comparision with division between sampled value and Z (to check whether the voxel clipped).
I think that the way that texture works is it is actually just a map that is used to alter the density of voxels that the bullet ray passes through (in screenspace relative to the intersection point with the ray). Purely a speculation on my part though, I only really have a surface level understanding of 3d graphics.
My favorite mystery I'm the whole puzzle. My story is a modeler told them to subdivide those voxels and they said, how big and how fast is the projectile.
@@vocassenpretty much my solution as well, if I'm following you right, though I added a step to animate the effect and increase the granularity of edge activity around the time/speed and space where a projectile would cavitate in line with its bullet physics model on the engine...
Cool stuff.
How on earth do you make these videos somewhat educational and engaging at the same time... also casserola lmao
I wrote some volumetric clouds a awhile back and on the topic of curl noise: consider bitangent noise instead. The main feature you want from curl noise is the zero divergence aspect, and you can get there in two gradients instead of three so it's cheaper if you're generating it in realtime, which is worth doing for your zero-divergence component
You are serving a niche in the gamedev community that feels halfway between sebastian lague and dani and I love it. Hope to see more soon :)
I'm a bit disappointed; I was like "who's dani" and thought he'd be the absolut dev professional with knowledge equal to black magic, but realized his contribution in your analogy is the presenting style instead
I'm astounded by this video. In like half-n-hour you explained 3D coordinate systems, noise, ray marching, several properties of light, BAKING, a fill pattern that's re-usable within the effect, plus five or so other prosperities on top of almost replicating the smoke effect. Pretty amazing you did this in less then a month tbh.
13:00 Now wondering how in the world Teardown's lighting is so good. Since all their level geometry is dynamic, they can't really bake anything right? 🤔
that's because teardown has no triangles. It's always working with voxels so you don't have to do any conversions
I sometimes think he talks too fast to understand everything. But that's alright, if you want you can try to rewatch it bit by bit.
@@heliusuniverse7460 then how does it do dynamic geometry that's not aligned with the voxel grid (and is rotated)?
Teardown uses full fledged raytracing
@@vibaj16 Probably domains.
Maybe the magical bullet hole texture is used to mask out the part where the bullet was shot before it is recomposited back into the main frame
My jaw dropped at the ray marching technique, it’s truly unbelievable how clever some of these concepts are.
wake up babe new acerola video dropped
@darkxseries7can confirm
I downvote this comment every time i see it
Thanks babe 🚬☺️
He makes me tired
@@SirNightmareFuel I think your holding that cigarette the wrong way
Math buffs and programmers must have some form of insanity to think like this. I get what's going on in a simple way, but to keep track of all of these functions and then stick them together in a functional way is simply astounding. What's more is that they've figured out how to make this stuff get calculated quickly. This is why I try to never give game devs crap when they do silly stupid things that break stuff. They've already achieved feats that I can't even begin to touch.
Well, to be fair, we didn't figure out how to make this stuff get calculated quickly. That's the GPU and whoever designed that already figured it out for us.
We just figure, "Hey, if we do this thing 36000 * 800 times, it'll be slow. Let's try to reduce those numbers." :)
I'm not an expert at all, but the bullet holes look like 2d composites on the final alpha matte, and if you move away from the line of the bullet another duplicate of the texture slides to obscure the hole.
Should be extremely basic and fast
This makes sense.
And maybe only visible client side? Haven’t played it, so wouldn’t know..
Yes but looking at the footage it seems like it has depth. There is a bit more to that than only masking
@@Rivandu I don't think it would be wise to leave an effect that could confer a competitive advantage client side.
Another small thing about the bullet holes is that they react to the volume of the smoke. You can only create bullet holes near the edges, not in the middle (you might able to with continued shooting in the same place, not sure about that).
This was hugely impressive though. Great video!
Lot‘s of respect for how far you go here to make a video. Mad respect.
I'm currently ~2 weeks into a psychotic speedrun attempt at teaching myself how to make a halfway decent game from scratch so I can finally properly tell this visual narrative I've been mulling over for a few years, now that the message and themes of it feel super relevant to current events. Still sleep deprived from beating my head against shader code all weekend and been kinda feeling like none of it even really sunk in, but... for the first time, I actually feel like I kinda understood most/all of this. Normally your more technical videos tend to lose me early in, after which I'd only occasionally continue watching for the top notch presentation and entertainment value... guess I have some older videos to re-watch :p
howd it go?
howd it go?
Thank you. There's truly nothing quite as satisfying as listening to such a delightful and informative explanation.
Love the Goodnight Pumpum God reference 3:45
Could the bullet hole textures Valve used on the smoke have been used as perimeters for real-time textures? Like the flat textures on the portals in Portal made to look like the actual environment through the portal. And each perspective from each player in the lobby could be rendered separately, like the multiplayer in Portal 2. Just a thought.
I believe that is the case, but this alone doesn't explain the 3d effect. In CS2, when doing the depth testing through a bullet hole, each pixel takes from a seemingly correct position of the noise, creating a proper 3d effect:
The smoke inside fades into the surface of the smoke.
This leaves me to believe the ENTIRE voxel is ignored when it sees the bullet hole.
Then I'd be led to believe they have some form of client side ray tracing, but I do know how heavy on the hardware that would be.
i really like your humor, and i love shaders even more when i see your videos.
I do wonder if they have a global voxel grid, or if they make a local one when the grenade deploys. If you included simplified bounding boxes for your environment objects (which they might already have for basic collisions), it seems like the cost of setting it up might low enough.
I don't believe they do as the number of bound constant buffers doesn't change based on the amount of smoke grenades in the scene
Obviously the result is astonishing, a lot of work have been put into that! But I really admire the effort your have put into the explanation of the animation parts, that is soooo fascinating to watch... Thank you for that :)
Me: F*king amazed by the work and the results.
Acerola OCD: What? Still not enough?
Me: I never say that
Acerola OCD: Fine I'll simulate how light pass through particles differently
From the looks of it CS2 had a set amount of voxels the smoke grenade will emit and would flood fill to meet this limit.
The quality of this video is insane, super informative and so well structured, the effort you put in really shows!
For the bullet holes, I would've just thought they projected the texture through the smoke.
Keep track of every bullet hole's location and direction, then when sampling the smoke density you project the point you're sampling onto that plane and sample the texture that way. To make the hole get smaller further from where it was shot, you can offset the vector along which that point is projected.
I'm honestly not sure how efficient that is - I'd have to try it - but that was my first thought when I saw how the smoke works in CS2
Damn, this is impressive. The smokes look really good while keeping solid performance.
acerola you are a legend and one of my favorites youtubers!!!!!!! so happy to hear you are now full time
It'll be interesting to see the bugs we get with CS2's smoke, beyond what people have already tried there isn't much else that will give us so much raw information to speculate over.
Keep an eye out for smoke bug videos folks, that's all I'm saying.
I always love seeing your anime and manga references to the Monogatari series, Tatami Galaxy and more. But I really didn't expect a reference to god from Oyasumi Punpun at 3:45. Keep them references coming
That's incredible and even more incredible is that you share all of the code
I believe that the smoke hole could be a displacement mask that hides that part of the smoke, much like displacement decals but far more sophisticated, still confusing and amazed how it is done and how you managed to get close to the real thing.
Idea for the texture they use for the holes.
Maybe it is used similar to a volume texture in 3d by just scaling the height of the texture a lot into the volume and then they subtract it from the density.
Like a 3d decal.
Or they remove the voxels on hitting them.
that would work with the grenade explosion aswell.
Removing voxels would require a very dense voxel grid, far denser than the one shown in the video.
@@qqii could work for grenades, but the grid is definitely too coarse for those bullet holes
@@qqii maybe some displacement magic affecting the neighboring holes deals with that somehow because magic?
Maybe it's possible to project the hole's texture in word space and sample these projections during raymarching to influence density of the volume?
Rather than removing the voxels I think the texture is just used to negate the visual effects already induced by the smoke. Like, "if bullet hole texture shows black, do not show smoke effects here". Then fade that mask out over time with some function to give the smoke the appearance of refilling the smoke, when really it was still there the entire time.
I was going to give my opinion on how the decal texture might be used but I will instead respect your wishes and keep it to myself. I will also be implementing my idea in my own free time to prove thats how it works. I hope you look forward to it.
I don't get it. I'm stupid.
Nah, you aren’t.
No, we're stupid. Apes together strong.
Your not, it's just complex
I was gonna leave a support comment but 69 likes
Balls get shaved
Bro, this is incredible. As an armature myself my solution would have been to use a low res volumetric particle emitter with a set radius and have the particles kill themselves on any collision lmao
this is wildly impressive, I'm so fascinated with game development, and this was a hell of a journey, awesome vid bro!
Just extrude that bullet hole mask along the bullet vector, you get a irregular 3d shape with density. Take that into account when you do raymarching, you get a hole in the volume. It's probably the reason why the hole only appears for a very short time, because the more holes you got, the worse the performance.
this made me realize some extra reason to have smoke as voxels: replays. Being a competitive element, making the smoke visible in replay (and tournament transmissions probably also more important in this day and age) exactly as as played is fundamental
Wouldn't it be possible to deside the shape of the smoke by throwing particles and and then calculating witch voxel a particle is in and then and filling in the voxel. (And I mean throwing like 50 particles not just making particle effect smoke, so not rendering the particles themselves)
That way you don't actually have to pre-bake the whole map.
It also gives you the posiblility to make the smoke Dender if multiple particles are in the same voxel.
You could also only make a voxel grid at the moment the smoke is thrown and only in a certain range of where the smoke lands.
And only keep that grid for a the life span of a smoke grenade.
That way you minimize the amount of voxels that need to be rendered.
You would still have to make sure that shit dousnt break when multiple smoke grenades are thrown.
This smoke reminds me very much of the clouds and / or fog seen in Xenoblade Chronicles 2 & 3 and The Legend of Zelda: Tears of the Kingdom. Maybe Monolith Soft, who worked on both games, used a similar technique for nearby fog / clouds in their games.
Your skill to simplify such complex topics is simply amazing, I don't even know how to write shaders and 3d stuff but I love watching your videos
The bullet mask is probably just projected on the smoke volume from the direction of the bullet. It's just used to subtract density. This should work for all viewers. Imagine a negative projector for the density. Should be easy to give you projected coordinate of a world space point on the bullet mask, and it will form the nice cone. The resolution would be very high as the check can be done in view space not voxel space.
This prevent bullet interactions from two directions, no? If you shoot from left and someone shoots from right, you wouldn't see the right-left bullet hole inside the front-back bullethole.
I have no idea what you are talking about, but I love it so much. It would be cool to understand everything, but I also have fun just looking a the complexity of these examples. Thanks for the awesome videos!
Very well made video. As a fellow graphics programmer, its nice to see some love for topics like this. Kept me entertained throughout the entire video too. You've earned a sub
Congrats on being a full time funny internet man. Your videos are what keeps me inspired in pursuing a career in computer graphics. It's so much fun to watch your content, thank you
The smoke looks so realistic in some screenshots. It looks like you went into photoshop and cut out an image of dust, and then you just pasted it into a screenshot of a game.
that va-11 hall-a or whatever it's called banger did not go unnoticed
cheers
Absolutely amazing explanations and showcase with an appropriate amount of humor. I hope you continue to do what makes you happy and share it with us all!
Some thoughts on the bullet hole thing; it doesn't look like Valve does proper shading or "tunneling through" the volume either. I suspect that texture is used to simply mask the entire volume before compositing it into the scene.
The "black magic" is only a matter of how to place, blend and track the location and "angle" of the hole particle. Though the holes only last a few frames so it's okay if the solution isn't very precise.
This approach wouldn't work for bullet holes that don't closely match the camera perspective - but if you think about it, it doesn't have to since you don't see those anyway.
I remember hearing Breath of the Wild rendering everything under the water surface at half resolution, but it would then later be changed by a displacement map.
I think the smoke effect gets away with the low resolution just fine as is, but I wonder if a similar process might still be able to fake extra detail.
For your question about how they did the bullet holes:
It seems like a depthtexture/stamp/decal that is placed on the volume's bounds mesh (the two boxes you show at 5:05 ) while its projected along the camera vector through the volume till it hits the end of the volume (the backside).
This would be a cheap way where you can sample the normalized depth into the volume and compare that to the depth of that bullethole, if its a higher value then the texture, you just sample 0 for density, otherwise you sample the voxel's value. :)
Also on the approach to voxels you described:
I think it makes more sense for the voxels to be aligned to the bounds we see at 5:05 again instead of the bounds of the entire playable map.
Even at a theoretical 256^3 (akin to a 4K texture at 16.8 million pixels). that wouldnt be practical memory wise (especially given the low target platform of CSGO 2).
They may use something like depth cubemap captures or some other approach to querying the environment (Maybe collision meshes as they are pretty cheap? though they mostly live on the CPU not the GPU).
All in all great video! love the details you went into to explain the implementation!
Great idea, but what if you're inside the smoke and the decal is no longer in view?
@@Acerola_t The decal would be more of a implicit/virtual decal.
In shader its placed and oriented on the bounding box mesh face closest to you (akin to splatting it, but more focussed placement where the bullet travels through).
The depth at 1 (white) means it's the closest point and the depth at 0 (black) is the furthest point (other side of the bounds mesh).
Something like a virtual/Distance field/implicit plane would do the trick and be cheap as well.
@@kayvolbeda8669 does this create bullet hole interactions? I don't think you can shoot through from two angles and have the carved paths meet.
@@benshulz4179 Yeah, you basically do boolean type operation this way.
It does become more expensive with more bullet holes though, so you'd have to be careful there.
to someone who dabbles in 3d with some art school skills, the technical knowledge on display is staggering
yeppppppp
Incredible video, I will try this out myself, seems fun!
Meanwhile, a theory on the bullet holes:
When you shoot, it applies the smoke bullet hole decal (and decreases it's size over time) on EVERY voxel on the shot's path, including the voxels inside the smoke.
Then, when doing depth test for a pixel, we check if the pixel can see a decal from a voxel. If it can, it ignores that entire voxel for depth testing. So if we see all voxel's decals, we ignore all voxel's depth and see through smoke, in that pixel. But if we see two voxel's decals, we ignore only those two voxels' depth.
After applying noise, it should create a proper 3d bullet hole effect.
Explosion clearing might be the key here. It could in theory just mark voxels as "do not render" and then apply a smoothed explosion decal on every voxel which is touching those "do not render" voxels, then ignoring entire voxel per-pixel like above if the decal is seen.
Monogatari intro, I kneel
3:45 mmmmm nice little punpun reference, i liked it very much
It's hard to focus on the video when you use such banger soundtracks from some of my favourite games
it's to distract from my awfully monotone voice
@@Acerola_t its funny
Could use sparse octrees to dramatically increase resolution while maintaining performance however that does seem like it would be quite difficult to pull of on the gpu
The Godot community has been summoned.
I absolutely love the in-depth analysis. But also wanted to give kudos for the bg music selection. It's a nice surprise to hear Va-11 OST
I think they use marching cubes, mip map of a only one hole texture setting the angle on creating, and apply based on voxel of entry and position of bullet. After they use the entry and out of bullet to interpolate the animation.
If it were marching cubes then a mesh of the smoke would be bound to the render pass, but I am always looking for an excuse to use marching cubes
I have done this last year in my scratch(yes scratch 3d game) I basically made a lot of game object with collisions and used a lot of raycasts to find where hole in smoke was
Didn't watch yet but can say confidently: what a banger
You are my favorite gamedev youtuber and you actually inspired me to start learning a little bit of gamedev with your grass video (god that grass looks good), so I am very exited that you are going full-time and I hope it works out well for you!
Grade 11 phys and math coming in clutch to barely understand wtf u r saying
An idea on how Valve could be creating the holes is by using the bullet hole texture as a mask on the player perspective for the ray-marching to continue through the smoke. The mask is centered on the bullet hole and allows rays from the player perspective to avoid the marching early-stop. The size of the hole could when opening/closing could be the hole texture being scaled up/down using some non-linear function.
I love these videos! Seeing the smoke just getting small little improvements along the way and summing up to something that looks amazing in the end is like a story on it's own!
i think the answer to the bullet hole question is that they have a wholly separate system than the one you made, with a bunch of smoke and mirrors instead of it being straight volumetric rendering.
the way that the smoke would intersect and wrap around map geometry would use voxels and similar math as your model, but use a different rendering system.
if the voxels they spawned in the devvlog are just particles with a cube mesh in a voxel-like pattern and a world orientation, they can substitute the cube mesh with a typical sprite stack, render it facing client cameras, fill in the gaps with some function that uses actual volumetric clouds that only generates clouds off of a heightmap of existing sprites.
raycast intersects sprites, overlay bullet hole texture in a volumetric heightmap at the location of the sprite's equivalent of a face normal, each sprite card in the stack receives decreasingly mipmapped bullet hole texture overlaid onto the height map, volumetric clouds receive a hole as a result because every single card in the sprite stack has the same heightmap adjustment. use the actual cloud to blend edges between sprite card.
ive seen a lot of your videos they are very well made idk why you are so underrated please keep it up
I would love to see more similar stuff like voxel and volumetric fluids. I am quite a starting game dev and a tech enthusiast. I am currently having lot of fun understanding how even the quite complex programing and software works but rendering, especially realtime is something that I cannot find enough good materials, especially some interesting. And your videos are just that, by the way I have bought books from Invidia that you recommended in some older videos and they are really good thanks.
Thankfully it all kinda works the same for volumetrics, so if you read through the resources I put in the description I think you'll really accelerate towards what you want to do
as someone looking to try out game dev this video was super informative thank you for making this vid
Great video! Some really interesting topics and the end result looks awesome!
Considering high fidelity voxels. It might be worth checking out: "greedy meshing voxels fast: optimism in design" - handmade Seattle 2022
very impressive how maths, coding work together to create beautiful visual graphics.
Very good job bro I understood how these smokes are made in detail
it kinda looks like individual voxels are moving in the csgo version so they might be using some system where either voxels atthe edge of the smoke can be squished a bit to have a more precise edge or they're making a small local voxel grid for the grenade that moves in itself and is only as big as the smoke radius
This is really cool.
While I'm not currently doing/learning game development, I love learning about the trucks that developers use to make perfomant and visually pleasing graphics.
This is definitely something you excel at teaching and demonstrating at a good level of abstraction. It feels like you know just how much detail you have to share so that your videos are informative and engaging, while introducing topics/techniques that we could go research if we want more detail.
My guess on the CS2 specific holes is that they’re using some GPU buffer shenanigans, much like the Portals in Portal. How exactly they’d employ this strategy, I couldn’t tell you, but it’s my only good guess here.
Now this is really Brilliant Stuff
Great job. I see many have tried to recreate this effect, but it seems you are the first to achieve a result that is so close to the original solution.
Very good video as always funny internet man
Educated guess on the bullet holes: An array of matrices that project the bullethole texture to an orthogonal "tunnel-projection". Sample the texture and mulitply to density. The problem here is of course this would mean one sample/bullet/step. So a few more wild guesses: They reduce the amount of voxels by not having the whole map considered for the live smoke, but only inside the bounds, so they have fewer live-voxels, but can add additional info about bullets saved in there. For example each voxel only contains indices to the 2-4 closest bullets in the array, so only 2-4 texture samples are needed, instead of ~10-50.
Also I guess there is some prioritizations, for example preferring bulletholes parallel to the viewdirection before orthogonal ones, or middle lifetime before semi-appearing before disappearing.
TLDR:
- have dynamic voxels only in a limited area around the grenade
- save all bullets in an array
- prioritize bullets for each voxel, save the most importent bullets indices inside the voxel
- density *= tex2D(_BulletMask, mul(_Bullets[currentVoxel.bullet], samplePosition));
Bonus: as you can combine matrices basically for free, just multiply a perspective matrix and you got a bullethole that gets bigger towards the end
this looks closer to cs:go's artstyle than cs2s, and i like that
This is absolutely amazing work! The time invested, the writing effort, the experiments… genius!
Very interesting video, thanks for all this work! The progression of information is very well made, taking the audience to the relevant conclusions instead of simply dumping info
Nice video. Verry informative. And for someone that knows nothing about voxels, is pretty easy now to understand how the smoke works in CS2.
For the bullet holes, maybe the texture is used for how much smoke is removed by the bullet hole... I think all you have to do is figure out what part of a rectangular prism the point is in, translate that to the surface of a square that then is used to find the value of the bullet hole at that point, and then multiply or subtract the density you see at that point on the ray by the bullet hole texture at that point. Then you just need to either shrink the prism or change texture based on a timer.
I probably have absolutely no idea what I am talking about.
The video was already insane but the Sonny Boy ost at 15:05 is what sold it to me
As for how they did the bullet holes, could be that they compared each position to be sampled with each ray, with X and Y being the offset in the plane, and Z being the distance along the ray. Then they could sample the texture using X and Y, and compare the sampled value with Z to see if the voxel should be rendered or clipped. I do not know if that is necessary given that the noise already could provide for a good texture in the hole, but simplifying the SDF code from a cone to a cylinder sounds like a good start. Especially eliminating those ifs and sqrts would be top priority, which would be possible given the texture sampling would clamp out-of-bounds samplings, and the texture also providing the hole shape, not the sqrt.
So all we would be left with is a few multiplications, two divisions (scaling distance to the texture bounds), a texture sample, and a single comparision with division between sampled value and Z (to check whether the voxel clipped).
you have no idea how much i adore your videos, they have touched on something i've always wanted to know about but didn't know how to find perfectly
It has been more than 1 year since the upload of the video but no one got "Bake monogatari" until now it seems. With your editing, memes, name of the channel . And with your dedicated shelf, I can say you are an avid fan. How cultured.
someone finally got it holy shit
Some observations about the showcase video:
1. Bullets were always shot near the surface of the smoke (than the core).
2. Weird artifacts when grenade exploded on smoke.
3. No tube-ish shape when a bullet is shot through the smoke.
So, they probably used a stencil buffer and the random bullet shot texture is the stencil?
They didn't shoot near the core as it would give it away as a tube-ish shape would be expected.
The texture at 28:18 could just be used to modify the signed distance function.
Imagine a sample taken in the signed distance function. It has world coordinates, you can convert this world coord into a distance and direction from a bullet’s path. Convert this direction into a vector that describes a 2d direction from the bullets path to the sample point when viewed along the bullet’s path. Finally starting at the centre of the sample image traverse outwards by distance * bulletPathToSampleDirection. Multiply the distance by a random value for each bullet, maybe rotate the sample image for each bullet as well, and boom now the bullet hole looks smokey instead of like a cylinder.
Haven’t tested this idea, it might have flaws, but this is my guess on what they did there.
I always wondered how these insanely detailed clouds were possible in both horizon games, I'm glad I finally got to hear and see how they did it.
I think maybe the bullet hole texture could be a used as a mask that is wrapped around a half sphere very close to the smoke in order to enable it being viewed from all angles
Each voxel doesn't have to be 32 bits.
I'm certain that bitmasking would be useful here. You could store 4 voxels per 32 bits this way.
certainly could, but at the fundamental level, this is the case
@@Acerola_t I wanted to know if what I said would be correct outside of a vacuum, so I wrote some benchmarks. I'll edit this comment with the results when I'm confident that I didn't make any obvious mistakes.