[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vr / w / wg] [i / ic] [r9k / s4s / vip / qa] [cm / hm / lgbt / y] [3 / aco / adv / an / asp / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / qst / sci / soc / sp / tg / toy / trv / tv / vp / wsg / wsr / x] [Settings] [Search] [Home]
Board
Settings Home
/3/ - 3DCG



Thread archived.
You cannot reply anymore.



How do I make a rig (preferably in blender) where character limbs can be detached from taking damage like in Fallout??
>>
>>635738
You're not thinking of it from a programmer perspective
The limbs don't come off, the bone transform in game is just scaled down to something like 0.001 and then the 'stump' is activated and the gibs/particles are spawned
>>
>>635739
This... Kind of. You'd probably need secondary bones and some unique weight mapping in order to prevent unwanted shrinkage (should you take that route). It'd be fairly close to a normal rig, but you'd have an extra bone for each detachable limp. That bone would have a perfect seam delineation instead of a gradient on its weight maps. This way, you ensure that when you shrink the limp, you don't end up with a point. Instead, you's have a "sawed off" seam.

Honestly. I'd probably just find some way to split the mesh and toggle between the full limp and a stump. The limps mesh would still be attached when it gets blown off. However, its faces would be hidden. Instead, you'd render the stump (which itself always existed, but was hidden).

Just spawn a bunch of squibs, gibs, and particles at that moment to hide the toggling. The blown off limb would be its own separate object spawned when the limb is severed.
>>
>>635739
Don't need to scale it down to 0.001 when you can make the mesh stop rendering.
>>
>>635858
or just delete the entire mesh and spawn two meshes
1.)Body_gibbed01
2.)Limb_gibbedhand01
>>
>>635885
Best not to delete stuff in vidya games. The process of allocating and deallocating memory for objects is one of the biggest performance killers. They teach you to use "disable object" options for everything reusable in most tutorials; arrows, grenades or, in this case, body parts. You can swap an objects variables a lot faster than you can spawn and set a new object. It isn't a huge deal when you're only blowing one enemy apart, but you'd notice lag when the mini nukes start landing in groups of ghouls.
>>
>>635885
Great idea, then you need to create six dozen variations for each character to account for all possible dismemberments. Dumbass.
>>
>>635893
do you even know what gibbing is? gibbing =/ dismemberment
>>
>>635891
where did you learn that deleting stuff is a hog? any good garbage-collected language (heh) actually does just disable instead of delete. that garbage memory is generally only shuffled around and recycled when new memory is required for an allocation. “new” is the real bastard.
but yea object pools are critical when using shitty languages.
sage because not /3/
>>
>>635885
Gibbing isn't dismemberment, tardlet
Gibbing is full-on body fragmentation and was initially used as a way to save resources by not having corpses lying around.
>>
>>635916
Nothing to do with garbage collection, it is a Javaism that never stopped bouncing around. Even today you'll get university professors who will tell you that garbage collection is genius because it speeds up memory deallocation, which is the kind of retarded statement, wrong on so many levels, that is equivalent to good old Creationist drivel.

As long as your malloc was competently coded, free() is painless in C. C++'s operator delete(), which is only a thin layer on top of free() is also completely painless, assuming your destructor does not shit everything up.

And that's the crux of the problem, really. Memory deallocation is fast, but deleting an object is often not, because the destructor is non-trivial, and change several lists and tables in the video game. Better just hide the object.
>>
>>635891
>>635916
>>635923
>tfw /3/ is more /g/ than /g/
>>
>>635923
you switched from
>allocating and deallocating memory
to
>deconstructors

but yea honestly the reduced understanding of what’s going on inside of a 4-layer inheritance tree full of constructors and deconstructors is probably way worse for the program over its lifetime than any hardware issues like memory ever would be
>>
>>635739
This
Watch this at 3:00
https://www.youtube.com/watch?v=L66vRF5VOVM




Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.