Hazel's New Mesh System

[@Test-iv4pm]

Your engine UI is looking crisp. Each time you show it on screen, I think "oh he's going to show us something he built in this program" And then it's like... no, he's showing us the program itself.

[@BulletproofOutlaws]

Hey Cherno! I love how you’re stressing the importance of BUILDING something to find out where the flaws in your design are. I learned this lesson the hard way when I tried making an entire game with placeholder art, just rectangles and circles to represent things, thinking “I’ll focus on the gameplay and engine features and THEN do the art.” Of course when I finally started the art, the first sprite I drew & animated as I nailed down my look, revealed that half the features I spent all that time on weren’t needed, and the other half needed to be overhauled because I didn’t account for a bunch of little things like workflow or animation needs that weren’t in my imaginary visualization of how the art/anims would work lol And I had similar problems everywhere else, from switching levels and reusing AI to using shaders and particles etc. You never really know for SURE what you need or how your workflow holds up until you actually try to make something with it and then it’s often immediately blindingly obvious. If I had just tried to build a first level early on, I would have caught all of that stuff and saved myself a ton of hassle and demoralizing rewrites. Not to mention that seeing stuff coming to life in front of you, even if it’s a bit wonky early on, is a lot more motivating than just staring at boring ugly debug stuff for months on end, especially as a solo dev. I think it’s important to see some kind of visual progression now and then, and it gives you something to compare to…like you could re-make this cube dropping game in a few months and feel the difference between whatever the new workflow and refinements & features you have then, and what a struggle some parts of it are now, and that’s a rewarding feeling. My mistake is funny to look back on now, like wtf was I thinking lol But at the time it crushed me to realize how much time and effort I wasted driving in the wrong direction without stopping to look at the map, while thinking I was being clever. Anyway just wanted to say thanks! Your videos have been a huge help in learning about good game and editor architecture. I don’t even use C++, I use GameMaker lol but the structure and principles you explain all carry over into any language nicely. P.S. I love the long in-depth vids. You always sound worried that they’ll bore people but you give such good explanations and insights, and it’s interesting to see how someone with experience problem solves situations, and what stands out when you review your code or someone else’s code. We all have to refactor our own code at points and your vids demonstrate HOW to approach that process, like what to even look for or think about. Like your explanations in this vid showing WHY the mesh stuff needed to be reworked to allow duplicating the Blender hierarchy so each piece can have physics and shaders applied makes it all crystal clear. We can all look at the DOOM or Quake source code and try to learn from their end result, but we’ll never know WHY Carmack made X decision or what approaches A, B and C that he tried first looked like, or what was refactored and why, and what his thought process was for deciding how to do it and see him build it step by step occasionally having to throw parts out or rewrite them etc. Jon Blow had a good story where as a newbie coder he was annoyed with Carmack for not optimizing loading WAD files and then eventually as an experienced coder he realized that Carmack knew that it wasn’t vital to the user experience to waste much time perfecting that with limited manpower and time available. It reminded me of your vid from when the docking feature for ImGui came out and you decided to just integrate ImGui as-is and explained your reasoning behind that decision and how sometimes you have to lock down “this is just the way things will work from now on, it’s efficient and does what we need so why complicate it?” Those kinds of insights from you experienced guys are often more valuable than the actual code itself, in terms of helping us learn to think like a programmer, problem solve, and plan long-term. P.P.S. Every time you do a code review of someone’s code, you mention that you could talk about little details for hours but that it would probably bore everyone…it would be cool to see you try that just once to see what people think of it, like with someone’s small demo they send you to review, just go all out in-depth for hours pointing out all the stuff you spot and would refactor to make it optimal. Just to have at least one code review where you really let loose and flex your coding muscles to show “look how much even a simple little game like this can be refactored as you gain more experience and learn what to spot and better ways to approach things” Just throwing it out there! Lol

[@chrishopkins1909]

Love the clean UI on Hazel, looks awesome man!

[@sergio_mgg]

Really missed a chance of saying "it's a little kinda _meshy_" at 5:57. Jokes aside, I'm really enjoying this Hazel series. Your channel is the most helpful source for computer graphics knowledge that I've found. Keep it up!

[@AntonioNoack]

His discord can help you as well :)

[@zxuiji]

paused at 12:54, if I didn't mis-listen then by my understanding you're just treating every object in the scene as part of an model and the physics just switches the top level index for changes that the final variables are read from when fragmentation is to occur, so code would always follow one path like this: ``` while ( windowisopen(window) ) { for ( i = 0; i < parts.count; ++i ) { top = parts[i]; if ( top.parent ) continue; setchange(change) { setuniform( "change", loc + xyz_offset, "float", 3, change.xyz ); ... } renderpart( part, change ) { change += part.change; if ( part.parts ) { for ( j = 0; j < part.parts; ++j ) renderpart( part.parts[j] ); } else { setchange( part, change ); bind( part.indices ); draw( part.draw ); } } renderpart(top, {0}); } } ``` **Edit:** Realised I made a poor example, re-did the example to be more efficient and make a little more contextual sense

[@mironco9595]

Good job! The game engine is looking great and (apparently at the end of optimization *November* lol) it’ll be running great too!Also thank you for making the fbx import settings marginally less brain intensive than the Unreal Engine ones (:

[@wutoby1052]

Havn't seen this serie for a while, now Hazel Engine is really looking awesome!!

[@call_me_stan5887]

Yay! The video framerate is correct at last :) Cheers, Cherno guy! Outstanding work :)

[@Rumble_Ball]

You now have two files, but its still a static mesh. The mesh itself does not change vertex positions relative to the mesh origin. I would not make it two files in this case, as you now get ton of clutter in the asset browser. It would be better to handle it on the instance itself. Would be better for the artist working on a project, as they can just click a button on the instance to change the behavior. If you have two types of asset, the artist would need to replace the existing asset. Now you only have the source and the actual asset, thus you can just keep the source as memory blob inside the asset and thus only have one file for the asset in the asset browser. You can still link it to an external source file if you like, so the asset can reimport from it, or just change the internal source by dragging another source file over the mesh asset. On packaging you can get rid of the internal source blob. While editing, any artist would be able to extract the actual source data from the mesh, if the functionality is provided.

[@AlmightyFSM]

Why make a different file type rather than just an enum/boolean in the same meta-data structure? I feel like I'd want to import all metadata needed in one go, then just alter its behavior in Hazel based on the metadata. That way if I decided to switch from mesh to static mesh or vice versa, I don't have to re-import from source.

[@StarContract]

The way I have it in my engine is as follows - You have a class called CompoundModelInstance which behaves like a container for geometry and a list of materials. This is the basic "rendering building block" of any game. Then you have the following classes: Entity extends CompoundModelInstance and RiggedEntity which is an entity with a deformation, fk and ik rig that further manipulate the rendering of the model instance. To handle destructibles you would use dedicated factories + relations = tuples that describe relationships between Entities; For example, SpringAttached(e1, e2, k) is a relation that tells the updater of the scene that Entitie e1, e2 are connected with a spring of return force constant k.

[@LetThereBeMayhem]

Love to see how the engine is going. Great job!

[@zxuiji]

"october is just a number.... that doesn't make any sense" actually it does if you translate october to japanese which is "Juugatsu", in this case the "Juu" part is represented by the kanji 十 which means 10, so yes october is just a number :)

[@zaxn1234]

Doesn't the name for October come from the old Romulus calendar when it was the 8th month (Octo meaning eight, samae with September the 7th, November the 9th and December the 10th and final month of that calendar)... It really is just a number XD

[@mastaw]

​@@zaxn1234 Yes! I think that's how it works in many languages

[@salockingaming6246]

"Octobers just a number"

[@NoodleFlame]

aww sad to see a pre-fractured cube mesh, I had hoped you had written a dynamic mesh destruction system using 3d voronoi regions. Still the effect looks great and couldn't tell.

[@FunNooberCodingForBeginners]

I am not sure if I have pointed this out before but your engine is gorgeous! The interface does not look clunky or boxy like a engine like Unity. Besides the UI, the actual graphics the engine produce is also beautiful! You barely have anything in your scene and it still looks like a AAA production!

[@محمدالزعبي-ن9ظ]

So, next month is gonna be "No New Features November"?

[@StarContract]

Also - are you planning a dev log dedicated to a game project (not engine)?

[@watercat1248]

i don't use Hazel's but i like the idea off static and dynamic Mesh

[@neemaadam]

I can Imagine Hazel replacing Unity

[@VVac0]

Does Hazel support USD (Universal Scene Description) file format ?

[@KonradGM]

so i was trying to find it but am kinda lost, how did he went from previous engine ui to current one? hei s still using imgui?

[@Red-di7zb]

Ну привет :) Man, your game engine is getting better and better, it is awesome, I envy you : ), looking forward to see projects powered by your engine. Хорошего дня и удачи.

[@danishezwan9320]

2:19 the guilt is real

[@chancemcclendon3906]

Hey I love the project and its very interesting to watch it develop but I keep coming back to the same question in my head of what sets Hazel apart from UE4 or Unity or even godot. Just Curious

[@Leandro_SWR]

Will ".hsmesh" do anything else in the future or does it just serve the same purpose as .meta files from Unity?

[@mahdibahramian8526]

Is there any kind of dynamic/procedural mesh solutions in Hazel now?

[@sergeysharpov650]

Hi man, you have done a great job! Can I ask you a question? :) Do you sort objects before render to get ordering work? If yes, then are you doing it every frame? It would be great to get a link to the example or your piece of code ☺️ Thank you so much for your videos!

[@kingreinhold9905]

You can't just layer objects on top of each other according to their order, right? A chain for example is made of rings overlaying each other. So I guess the sorting system is calculated every frame, but not object-wise, but for each triangle of all meshes.

[@DFPercush]

z-order is normally accomplished with per-pixel depth testing on the gpu hardware. It involves a separate buffer in gpu memory for the depth of each pixel/fragment. Ideally you would want to draw things front to rear, so the maximum number of pixels are depth-tested out during rasterization. In that way sorting can help. Other techniques exist to minimize overdraw, like per-object occlusion culling. This can be a combination of cpu processing, like testing the bounding box of things, as well as gpu rasterization queries. You can tell the gpu to do a "dry run", draw the mesh without any shading but don't actually write any pixels, and the gpu tells you if any pixels would be visible. There are several ways to optimize the process, but most of the time, unless you're pushing some very demanding graphics, you can just rely on the depth buffer.

[@sergeysharpov650]

@@DFPercush it's not about z-order, thanks

[@sergeysharpov650]

@@kingreinhold9905 I think, as for the rings, it can be solved by z-order, I mean simple "order" or "layer", because as for some meshes it's hard to draw them in a correct order and you trying to solve the issue by setting an alpha/depth functions to each mesh part, but all of your need is just to render in the correct order :) (Also transparency ordering is similar to what I want)

[@MagnoVJ10]

Could you explain to us how do you managed to draw in non-client area like putting the menu items and changing the color etc...

[@santi5655]

thanks for the video cherno! this static mesh thing doesn't make much sense to me tbh. I would rather have a single mesh asset type, import as separate objects by default, and maybe have an import option to merge the geometry into a single object (which wouldn't be that necessary after all as children nodes will move with the parent). Also, the static word will probably be confusing in the future when you have baked lighting and stuff

[@ДанијелСтокић]

This guy is a god.

[@lobinuxsoft]

Beautiful ♥ ... I know it is not in your current plans, but my question is the following, when you finish the series of creating a video game engine (Hazel 2D), is there any plan for an upgrade of the series to move on to 3D the engine? ...

[@HAWXLEADER]

But November should be where Nodes everywhere makes more sense!

[@syth-1]

Great vid as always,

[@salockingaming6246]

I dont know a lot about hazel or game engines in general, but how does it compare to other game engines like Unity or unreal?

[@erich_l4644]

it doesn't, yet. It's mostly a pro's pet project.

[@danielmulholland5869]

Yo chern do you write music?

[@Jkauppa]

frame cube visible around the pieces, until it breaks

[@Jkauppa]

or use rigid models and replace/spawn with the pieces when it breaks

[@Jkauppa]

a tree object

[@Jkauppa]

mesh-sub-mesh models are easy to kinetic skeleton manipulate, milk shake 3D for the win

[@Jkauppa]

think like an animated hand in a robot tree object

[@kebrus]

I think this drag in scene to import is very weird in terms of UI/UX, importing a mesh and actually having it inside the scene are two different things, unity uses the inspector to render the import settings of meshes while unreal has it's own dedicated window that you get by double clicking on the asset, both are better because they are clear that you are only changing the import settings and not the scene data. You even got yourself confused about the two cubes because you assumed that when you dragged you only wanted to import the mesh. You could also have automatic/default import this way because it's not dependent on user action until you actually have to do it yourself.

[@TheCherno]

You can double click the asset to open it in its own window/viewport with extra settings(like Unreal), this is just a quicker workflow

[@S41L0R]

This is gonna be interesting

[@exhilex]

Unity + Unreal = Hazel

[@IBrinkI]

@The Cherno PLEASE revisit Halo Infinite's new trailer that was released a few days ago. I found your channel after seeing you break down just how bad the E3 2020 reveal was. Curious to see what you think of the graphics now.

[@bopon4090]

So how to download hazel?

[@gigachaddest]

wot , a , legend.

[@MetinCloup]

can you make a game engine with java after hazel?

[@feschber]

just not really a good language for game engines

[@AnsityHD]

(int)Month::OCTOBER == 9

[@ralfwright]

Behind the scenes maybe months are just integers? **looks at binary** Oh wait... Fr though October could just be 10

[@AnsityHD]

@@ralfwright October is 9 if the enum is zero based :p

[@ralfwright]

@@AnsityHD right, I forgot. Worst programmer ever 😆

[@7secondstiltheend160]

What's it like to live in the worst city in the world in terms of lockdown restrictions?

[@marknn3]

The origin positions of the fractured-cube and the orange-cube are not identical. That's why the fractured cube 'jumps' when you 'fracture' the cube.

[@syntaxed2]

God I hate Blenders GUI - Even Hazel, a one man spare time thing looks 100x better :)

[@BetaChri5]

i like blender ui

[@erich_l4644]

bro can you just help out on the Godot project? Sorry but... I mean come on =P

[@JarppaGuru]

like yet another unity unreal. why need learn new?

[@sleep3017]

Yooo

[@cankarkadev9281]

5 likes and 1 view … nice :D

[@oamioxmocliox8082]

;)

[@retr0aherojumper]

first viewer

[@yousefzk22]

you win , congrats :))

[@RogyDev]

;)

[@pytax9885]

;)

[@JustARegularPlayer]

;)

[@Skulltroxx]

;)

[@thiccpotato4021]

;)

[@pkpandrakula5199]

;)