Topic: [Unity] Fantasy asset pack prefabs

[ratty redemption]

Hi everyone, i've been working with kat's meshes and textures from his commercial fantasy set. i will be offering for free my unity prefabs here on katsbits, for anyone who purchased his set. when i've finished converting all his meshes to prefabs, including writing scripts for some of the dynamics. it's a lot of work as it's well over a 100 of them. i'm currently about 80% done.

In the meantime here's some screencaps of one of kat's dynamic levers (which i'll be adding scripts to in the near future) as well one of his static archways. the green boxes are the unity compound colliders, and are child objects of the parent container object. the mesh renderer is another child object.

The red version is just a couple of colored directional lights i use when working with the primitive colliders to help them stand out more, the original stone and wood materials are unmodified.







[EDIT] topic split from original here, as it deserves its own discussion. kat

[ratty redemption]

if i remember correctly, the main reason for using unity's built in colliders as opposed to mesh colliders, is the physic engine is a lot slower at testing each tris in a mesh, than it is testing the primitive shapes like box, sphere and capsule, even when there are more of the latter.

so while it does work using a collision mesh exported from blender, our games should in theory run faster if we keep the mesh colliders to a minimum, for example a terrain, which would be impractical to build using primitives.

[ratty redemption]

this image shows a collision test i did to work out if we could use box colliders for roundish prefabs. although the results are pretty decent and performed well with my own character controller, the amount of transform rotated box colliders were too time consuming to use in production. so i'll likely use a single convex mesh collider for cases like this in the future.



these next three images show a light blocker sub object. this is used to fix light leaks in the real time shadows. apparently certain step, or corner shapes, in the render meshes can sometimes produce thin streaks of light where shadows should be cast.

[kat]

Noicely done (nicely done)!. Helps clear up the discussion under the Unity collisions video as well.

[ratty redemption]

he he, thanks kat.

[ratty redemption]

although this wooden crate is not included in kat's fantasy set, it will hopefully be available in the future, along with other similar dynamic prefabs.

the first image shows the cracked parts of the crate still fitted together, which kat modeled in blender. as this was a test it's not the final version, but gives an indication of what is possible.

the various broken parts are held within a parent prefab. basically a unity empty which acts like an origin for the group of rigidbody objects. the yellow gizmos are my force points, as i call them. level designers will be able drag the tips of these around the 3d scene, in order to instruct my breakable script to apply an explosion like force in the direction of the tips.



the second image is half way through the crate exploding apart. the length of the yellow gizmos don't actually affect the amount of force (speed) of each child object, instead that variable can be set as a random range within my breakable script's inspector options.

the unity console window is also printing out the results of my object pool script. which is a type of manager script that recycles dynamic objects like bullets, breakable objects, collectibles etc.



i'm also experimenting with the amount of damage that my health script passes to the breakable script, possibly affecting the explosion force.

so in theory if the player jumped up and down on top of a dynamic crate, then it might just crack apart after it's health runs out. whereby if the player shot the crate with a rocket, or dropped down from a significant height, then the crate might explode.

[ratty redemption]

i've been busy the last 3 months, mainly switching from monodevelop to visual studio for code writing. it took me while to learn and configure vs, as it's a lot more complicated than mono. i also made my own fonts and colors interface theme for it.

anyway, i'm back on track producing content again... this 1st image shows some test results of me getting gizmos cubes to rotate correctly, using a script that reads from the inspector's transform component. unfortunately this is not a feature built directly into unity's editor when it comes to gizmos, but it's very useful. especially when creating visual aids for prefab objects like spawn points. as seen in the 2nd image.



my script displays a single boolean checkbox in the inspector called "is character". if ticked it will adjust the scale and positions of some of the gizmos parts.



this script doesn't actually spawn anything. it's just the visual aid for the position and rotation that a spawner script would use.

i will be releasing all the scripting and prefabs i show here in the future, unless they are superseded or prove to be unstable.

[kat]

Very nice.

[ratty redemption]

thanks kat.

[ratty redemption]

i'm getting on well with writing a script based trigger system, to replace the in built unity one. mine does use some of the unity functions like "Physics.OverlapBoxNonAlloc" but it doesn't use "OnTriggerEnter" etc.

it has optional features like matching trigger id to colliding object's id, combined mass of colliding objects for pressure pads etc and different update speeds.

the latter can help with performance, as the "slow" option only checks one trigger volume per frame, as opposed to "fast" which loops through all triggers every frame. there is also an "auto" update speed, which dynamically switches between the the other modes, depending on what is going on in the game.

it's a manager and data system. meaning the scripts attached to the empty game objects that turn them into triggers are relatively small, as they contain very little, if any logic, and no update functions. the logic and updates are processed in the manager, after it has found and populated a list of triggers at start up. i'm also writing a series of other managers to handle different aspects of the gameplay.

below are some screencaps of this work in progress. note the verbose debug logging in the 3rd image is not displayed by default, it's just an option that level designers can toggle in the unity inspector, mainly for the purpose of tracking what the triggers are doing, if needed.

although it looks complicated, the end result should be straight forward for most level designers, as it's based on drag and drop and check box interface design. in theory it should only take a few minutes to set up, once someone follows the step by step instructions, that myself or kat will write in the future.

[ratty redemption]

one of main the reasons why i wanted to write my own trigger system, albeit using one of the built in unity physics functions, was to reduce the amount of function calls. especially to the target scripts.

although my trigger manager script does read and write a lot to it's data scripts, the latter only contain a few lines of code each. so in theory this system when finished could be faster than the unity built in function "on trigger stay", possibly also the "on trigger enter" and "on trigger exit".

in the 1st image we see my trigger data script for a lever object has been set to use "activation auto". which would normally be used for  doors that don't require manual activation, other than the player or npc's walking up to them. i was just testing using the lever, but it could have been any object that can be triggered.



keep in mind, the unity debug logs printed in the console window, do significantly slow down the game, so most of the time we'd have them disabled. with that being said there is only a couple of function calls from my trigger manager to my lever manager, and that was due to me moving the player in and out of the trigger volume, which the data script is attached to.

compare that to the much higher "fast update index" and "collider count" logs, which are keeping track of all the dynamic collider objects inside the trigger volumes. in this case just the player, but could be lots of objects inside several different volumes, which the manager cycles through when it does it's fast or slow update.

to clarify, this system acts like the built in "on trigger stay", except it only calls the target scripts once per "enter" and "exit".

in practice, if this was an auto activated door, it would open when the player walks up to it, ie enters a trigger volume. then the door would stay open until the player had left the trigger volume, on the other side.

my trigger data scripts can also be set to "use once" in which case the manager removes them from the game after the "enter" event, so frees up some memory and cpu.

the 2nd image is similar to the previous test, except the data script is set to manual activation. that can only call the target script when a player is inside the trigger volume and using a "activate" key input.



there is a short timer delay between those function calls so the player can't keep spamming the input. in the future, i might make the delay an inspector variable, so level designers can choose their own values. but for now having a delay of about 1 second seems to work well. if there was no delay, then there could be 30 or 60 functions calls a second to the target script if the player held down their activation key. which would be a waste of resources, and eventually slow down the game.

[ratty redemption]

these images show two of kat's lever models made in blender, and being animated in unity by my lever manager script. my inspector variable "end angle x" is used in the 2nd image to limit the range the lever can rotate, so it doesn't pass through it's base.

[ratty redemption]

after a lot of experimenting over the last couple of weeks, i've nearly finished the lever manager. the following post is related more to the code than level design...

1st image is the whole of my lever data script. these would be attached to each of the lever prefabs.



level designers could replace the meshes and textures with different versions if they wanted, as long as the prefabs followed the hierarchical structure of the ones that i'll be releasing, hopefully in the near future. alternatively coders could edit the scripts to suit their own designs.

lines 17-20 are what we're focusing on here, as they are used to store the reference to the prefab's pivot, the start and end rotations, as well as the target rotation. the latter toggles between start and end when the lever reaches the target rotation.

2nd image is part of my start function of the lever manager script. the various managers are attached to an empty game object in the root of the scene's hierarchy window. there is only one manager of each type.



lines 89-92 are assigning the initial values to the data script's variables. the most important, and difficult for me to figure out, was line 91. which is the end rotation.

to my surprise, that line didn't require at this stage, any reference to the pivot. instead it's using my inspector variable "end angle x", which defaults to 90 degrees. it also references the vertical "y" axis of the prefab parent, ie the lever base.

3rd image is part of the "fixed update" function (ie physics update) of the manager script.



line 126 is interpolating between the current rotation (taken from the pivot each frame) and the target rotation.

i was surprised by how high the "250" value ended up being, as that determines speed per second. normally i move or rotate objects with values between 5-25. i guess it has something to do with converting that value to degrees, but it's still weird looking. any less and it was moving too slow in my opinion.

that value could be exposed in the inspector for the lever designers, but for now i'm leaving it hard coded.

another thing which i'm still trying to comprehend, is the beginning of that line has "leverData.pivot.rotation = " which means it's not just storing the interpolated value in the data script, but also apparently applying it to the actual pivot, rather than a reference to it. i assume this has something to do with "reference types vs value types" although admittedly i'm not good at distinguishing the former.

in the past i would have done those separately. it was actually a typo that i wrote it like this, but it produced good results so i kept it.

...

a longer version of the lever manager script that i got working a couple of days ago, took a slightly different approach. in that instead of interpolating between start and end quaternions, i broke it down to interpolating a "current angle x" floating point variable, similar to the "end angle x" previously mentioned.

i then used a built in quaternion function to construct the current rotation from the "x, y, z" and applied that to the pivot.

the reason i had tried that was i wanted more control over each frame. so in effect constraining the "y" and "z" axis so there was no unwanted drift on them. turns out i didn't need to do that but it's good to know we can if need be.

in summery, it was a lot of hard work to get the levers to behave as i wanted, although i learned several very useful things in the process... there's even a couple of interpolate functions that i tested, that have acceleration and deceleration in their movement. in the end, i opted for a constant speed for these levers as that seemed more natural.

[ratty redemption]

forgot to mention, this type of code can also be used for tanks or turrets where the parent object is rotated in one direction and the child object faces another.

i'm currently working on the door manager, which will switch between sliding and rotating doors, depending on the door data scripts.

[ratty redemption]

this image shows a test room i built with 25 of kat's lever models. i didn't notice any drop in fps while they were moving, which surprised me.

take into consideration there is only one invisible trigger, and one real time light, which doesn't cast shadows. so this was really to test if the scripting and animating geometry was expensive.

if we had shadows on or more lights, it would slow down to some degree.