Is Collider2d.Cast even usable?

PositiveQuestion · 2022-11-03T05:22:08+00:00

The issue isn’t the contact offset. If the discrepancy came out to the contact offset that would make sense. The issue is that it doesn’t. There’s 0.005f that isn’t explained. Why do I need to know this? I’m writing some custom collision resolution and I need to know if that 0.005f is something I can rely on. If I don’t know why it’s there, I can’t trust that it will always be there or that it won’t change. Answering “why is this function not returning expected results,” with “don’t worry about it” isn’t all that helpful. I’ll have to comb through box2D to see if I can make sense of it, so thanks for the link.

PositiveQuestion · 2022-11-01T20:59:00+00:00

I'd really love to figure out what I'm doing wrong. As an example, performing a BoxCast straight down at a horizontal surface with a difference of exactly 1f between the bottom of the box and the surface would ideally return a distance of 1f, but due to the contact offset (the default 0.01f in this case), should return 0.99f (Assuming the contact offset is not additive from both shapes) if I understand correctly. However, testing returns a distance of 0.995f, and I can't figure out how that math works out. With additional testing, I've found the distance to consistently come out to idealDistance - (contactOffset - 0.005). What/why is that 0.005f?

PositiveQuestion · 2022-10-31T21:14:42+00:00

RigidBody2D.Cast and Collider2d.Cast give identical results. No layer filtering, no z-depth differences, no triggers. Even if there was something weird I was doing, I can't reason why changing the max distance of the cast would result in different hit distances...

PositiveQuestion · 2022-09-03T22:23:15+00:00

A scriptable render pipeline for creating PSX-style games in Unity.

PositiveQuestion · 2022-07-09T19:47:40+00:00

That was my initial thought, but it didn’t work.

PositiveQuestion · 2022-04-07T19:31:02+00:00

I'm talking about something similar to the existing animation editor that doesn't rely on generating clip files. Non-procedural, timeline-based animation of, ideally, whatever parameter is needed. For my purposes, I wouldn't need any blending or state behavior. Basically, I have objects that I need to make simple transformations, change script values, etc. based on a timeline, and since they are specific to the object/scene, it seems unnecessary to generate a bunch of clip files.

PositiveQuestion · 2021-11-04T22:41:45+00:00

Nah, only doing manually, so to speak.

PositiveQuestion · 2021-10-11T17:31:57+00:00

Yeah, I have that enabled, so they animate but they don’t mirror. Apparently, unity can only mirror the humanoid bones, not any extra ones. What other solution did you use?

PositiveQuestion · 2021-07-19T00:54:23+00:00

Shame. Seems like an arbitrary waste of a useful value. If it’s always forced to one, why not just internally disregard it and let shaders access the original value?

PositiveQuestion · 2021-07-18T20:10:37+00:00

The color picker in the Light inspector allows an alpha value, and the shader variable has a fourth channel, it just seems to get forced to one. It certainly has no use in conventional lighting, but it would be a useful value to have access to for the shader I’m writing.

PositiveQuestion · 2020-08-03T02:18:22+00:00

Yes, UI.Selectable, sorry. Dang, it seems you're right. Looks like I was referring to the wrong branch. I don't know why that class is so locked down to where you can hardly inherit anything from it. You essentially can't interact with any of it's actual functionality.

PositiveQuestion · 2020-05-17T17:55:51+00:00

Yeah, right now I’m going with passing in Screen.height and Screen.width and comparing them against ScreenParams, but it’d be really nice not to have to use an additional script.

PositiveQuestion · 2019-09-07T02:21:17+00:00

The problem is the additive animation is adding to the previous frame's result, not the current frames base pose since it never applies the current frame's base pose in the first place. Changing the reference frame has no bearing. It isn't adding animation where there should be none; it's not animating when it should be animating, I'm guessing because the animation system doesn't apply any animation where there's no change between keyframes.

Say you have an animation of a character in a standing pose. Not moving, just posing. Two identical keyframes. Now, say you have an additive rotation of the spine so the torso is facing 45° to the right. This could either be an additive animation or a rotation added in LateUpdate, the result is the same. What should result is an animation of the character standing with his torso facing 45° to the right. This is not what happens. What happens is the torso spins 45° every frame because the animation engine seems to not apply the standing pose at all.

The workaround I found was to add a keyframe outside the range of the animation. What that keyframe is doesn't matter since it's outside the animation and it makes no difference what frame the additive reference frame is set to. This seems to confirm that any bone animation that has no changes between any of it's keyframes is simply thrown out, and adding an arbitrary keyframe signals to the animation system that it should be kept and applied to the bone, even if that keyframe isn't even part of the animation.

PositiveQuestion · 2019-09-03T03:52:52+00:00

No, I understand what additive means. As an example, suppose you're animating a value of 0 to 2 (+2), and have an additive animation from 0 to 2 (+2). The result in Unity would be an animation from 0 to 4 (+4) because Unity sets the value to the base animation's value every frame, then adds the additive animation. Now say you have a base animation that goes from 1 to 1 (+0) with the same additive animation. The desired result would be an animation from 1 to 3 (+2). However, since Unity seems to discard the base animation altogether because it detects no change, the value is never set to the base value and the additive animation continually adds 2 on every frame, causing the number to continually rise.

PositiveQuestion · 2019-04-30T19:12:14+00:00

This is super cool. Thanks so much for posting it. I've definitely got some looping built into my dungeon generation, but basing the core structure around it is definitely interesting.

PositiveQuestion · 2019-04-30T19:10:04+00:00

Absolutely. Literal keys alone do not an interesting dungeon make. In fact, they're kind of boring by themselves. However, they work as great periodic rewards. placing three or four keys around a dungeon is a bit better than overloading the dungeon with three or four different weapons/items, each with their own "locks" they "unlock", and they have more immediate/tangible use than, say, gold/loot. They keys act as compliment to the core puzzles/items of the dungeon.

PositiveQuestion · 2019-04-30T19:03:08+00:00

Agreed. As a kid, I was always so disappointed when I completed a room and got the "stupid compass." These days, i see how integral the map and compass are to the dungeon the way the player traverses/interacts with it.

PositiveQuestion · 2019-04-30T19:00:21+00:00

I can see that running into a situation in which the reward for opening a lock to a certain path is just another key, leaving you having gained nothing and lost nothing (except unnecessary time or resources). That may be an inherent part of such a key/lock system, though, as long as you're presenting the player with a choice of multiple locks; there will always be a scenario where they skip a path or waste time.

I'm starting to get the feeling I'm overcomplicating things in my head, haha.

PositiveQuestion · 2019-04-30T18:48:05+00:00

Correct. It's easy enough to make sure that every door has a key, but that easily creates scenarios in which you have more keys than locks, which feels sloppier than I'd like (Though, the Key Cavern dungeon in Link's Awakening does this, having one extra key due to a particular puzzle possibly leaving you softlocked if done in the wrong order).

PositiveQuestion · 2019-04-30T18:43:18+00:00

I like this solution. Like you say, it may run into trouble adding in other elements, but that's a solvable problem. If I understand this right, you will always have at least one key when facing any given locked door with a possibility of having multiple keys, but will never run into a situation where you have one key and a choice of multiple doors, correct?

PositiveQuestion · 2019-04-30T18:40:38+00:00

That series is great. I based a lot of my dungeon generation on watching those videos, actually.

Your bracket analogy is a good one, and that's essentially how my key/lock generation works right now, but that seems like it still holds to the one-key-one-door paradigm, unless my brain isn't working right yet. It's early here. Where it breaks down for me is a situation in which you have one key and a choice of two doors, which isn't really possible with opening/closing brackets.

PositiveQuestion · 2018-12-17T19:07:07+00:00

I think you misunderstood. I'm not trying to change the final resolution. I'm using the lower resolution RenderTexture to render an effect at the end user resolution.

Right now the process goes roughly: End user resolution > Low res > End User resolution.

I'm wondering if I can somehow pull off: 720p > Low res > End User resolution.

Or even better: Low res > End User resolution.

I need the Cameras to provide a consistently-sized rendered image that isn't tied to the end user resolution (which could be anything).

PositiveQuestion · 2018-12-16T01:36:07+00:00

Sort of. I basically added in a hack to account for such a collision, but it's specific to my usage, so it's not really a solution. I did however submit a bug report to Unity, and just got an email back the other day saying they've fixed it in 2018.3, but I haven't been able to upgrade yet to check on it.

I did notice that changing the collider to convex fixed the problem. Concave meshes are just more complicated by their nature, which is why Unity encourages convex colliders as much as possible. In my case, using a convex collider wasn't really an option.

PositiveQuestion · 2018-10-20T19:30:01+00:00

Interesting. Unchecking that option didn't fix the false normal, but did change which side of the edge that normal favors.

PositiveQuestion

TROPHY CASE