April 12, 2018 - abstract classes, materials optimization, joints
April 12, 2018 - morning dev:
"Pretty massive update spanning yesterday evening and this morning.
Yesterday I focused on using an abstract class (something new I learned recently) called Cuttable which I'm attaching to all cuttable objects and for starters I'm using it to assign a unique cap material for the object. You can only really see it on the thin sticks which have a really weird outline looking material on them when cut.
I also added the ability to simplify the materials once the hot metal has cooled. This would eventually assign the exact same material to all cooled chunks resulting in a render speed increase.
This morning I had a look at my joint connections which are keeping the cuttable objects (cube, sphere, column, etc...) anchored, as well as holding together the weird floppy rigged thing. I found a much better way to calculate which cut chunk stays attached to the joint so if you're looking for it, the springy weird thing cuts a lot better now.
I still need to have the joint connections break apart correctly. I'll probably deal with that next.
Anyway, this update might seem small but in my mind it's huge. What's nice is that after about a 20 minute long testing session I really felt like the system was robust. I really never felt like the object pool got overloaded and had to sacrifice any chunks. Right now it is limited to 250 chunks. The joint connection glitch showed up only once. This is where if I'm in a cutting frenzy the anchored chunk is floating in space high above the platform.
One thing that is really irritating is that I can look up the abstract class on an object via GetComponent<Cuttable>() which would return the inherited class, something like CuttableMetal. Now when I got to Add this component to a new chunk I get an error where it doesn't understand the System.Type(cuttableComponent) that I'm giving it. So, I've had to hard-code it into a shitty switch statement. I'll clean that up later but stuff like that drives me nuts.
"Pretty massive update spanning yesterday evening and this morning.
Yesterday I focused on using an abstract class (something new I learned recently) called Cuttable which I'm attaching to all cuttable objects and for starters I'm using it to assign a unique cap material for the object. You can only really see it on the thin sticks which have a really weird outline looking material on them when cut.
I also added the ability to simplify the materials once the hot metal has cooled. This would eventually assign the exact same material to all cooled chunks resulting in a render speed increase.
This morning I had a look at my joint connections which are keeping the cuttable objects (cube, sphere, column, etc...) anchored, as well as holding together the weird floppy rigged thing. I found a much better way to calculate which cut chunk stays attached to the joint so if you're looking for it, the springy weird thing cuts a lot better now.
I still need to have the joint connections break apart correctly. I'll probably deal with that next.
Anyway, this update might seem small but in my mind it's huge. What's nice is that after about a 20 minute long testing session I really felt like the system was robust. I really never felt like the object pool got overloaded and had to sacrifice any chunks. Right now it is limited to 250 chunks. The joint connection glitch showed up only once. This is where if I'm in a cutting frenzy the anchored chunk is floating in space high above the platform.
One thing that is really irritating is that I can look up the abstract class on an object via GetComponent<Cuttable>() which would return the inherited class, something like CuttableMetal. Now when I got to Add this component to a new chunk I get an error where it doesn't understand the System.Type(cuttableComponent) that I'm giving it. So, I've had to hard-code it into a shitty switch statement. I'll clean that up later but stuff like that drives me nuts.
"
Comments
Post a Comment