Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Zaphod42
Sep 13, 2012

If there's anything more important than my ego around, I want it caught and shot now.

supermikhail posted:

Oh, dear... So do I want Unity serialization or... C# serialization? I guess it's probably up to me.

I don't use Unity, but reading that page real quick sounds like explaining what Unity does internally to serialize certain values, not a Unity method of serializing.

So if you need to do your own serializing, I think the answer is the standard .NET C# Serialization approach. HTH.

Shouldn't be too hard to just load a library, throw some object at it with the right annotations and get it to spit out some JSON for ya.

Adbot
ADBOT LOVES YOU

ShinAli
May 2, 2003

The Kid better watch his step.

supermikhail posted:

Oh, dear... So do I want Unity serialization or... C# serialization? I guess it's probably up to me.

Yeah, didn't mean to confuse you. Pretty sure you want C# serialization.

Inverness
Feb 4, 2009

Fully configurable personal assistant.

xzzy posted:

I've become a huge sucker for yaml these days, I love the look of the files (they're super easy for a human to edit) and importers/exporters exist for just about every language. I'm sure Unity has one too. I know it does json as well, which is a reasonable alternative for serialization.
JSON is a subset of YAML, so you can convert your YAML into JSON in-memory if necessary.

This is how I bolted YAML support into an existing program.

Sistergodiva
Jan 3, 2006

I'm like you,
I have no shame.



So, I want to know if I have line of sight to an enemy. I guess I should use raycasting for this?

Right now I handle my collisions in a layer in my tiledmap, but I could probably make some polygons in a object layer which I could use for collisions, since there are stuff you should be able to shoot through, but not walk through.

Does this seem reasonable? Any good guides to raycasting? I'm guessing I use some kind of line and check if it intersect my polygons?

Wolfsbane
Jul 29, 2009

What time is it, Eccles?

supermikhail posted:

Oh, dear... So do I want Unity serialization or... C# serialization? I guess it's probably up to me.

I think you need to say a bit more than "serialise my stuff" if you want advice. What are you trying to do, and why are you trying to do it? Serialisation is a solution to a problem, and without knowing what your problem is it's hard to recommend a solution.

ToxicSlurpee
Nov 5, 2003

-=SEND HELP=-


Pillbug

Sistergodiva posted:

So, I want to know if I have line of sight to an enemy. I guess I should use raycasting for this?

Right now I handle my collisions in a layer in my tiledmap, but I could probably make some polygons in a object layer which I could use for collisions, since there are stuff you should be able to shoot through, but not walk through.

Does this seem reasonable? Any good guides to raycasting? I'm guessing I use some kind of line and check if it intersect my polygons?

That's one way to do it if you have colliders set up. Since you're using tiles you can use Bresenham's Line Algorithm.

https://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm

Use that to get the tiles that are in a line between thing A and thing B then check if any of them block sight along the way.

HappyHippo
Nov 19, 2003
Do you have an Air Miles Card?

ToxicSlurpee posted:

That's one way to do it if you have colliders set up. Since you're using tiles you can use Bresenham's Line Algorithm.

https://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm

Use that to get the tiles that are in a line between thing A and thing B then check if any of them block sight along the way.

This is the right approach but that particular algorithm can be problematic because it jumps along diagonals. For this situation you want something more like this: http://www.redblobgames.com/grids/line-drawing.html#stepping

Nition
Feb 25, 2006

You really want to know?
Speaking of colliders and algorithms, one thing that's caused me endless headaches in my current game is calculating weapon movement ranges. Every weapon is a turret with some amount of X (pitch) and Y-axis (yaw) movement. Never any Z-axis (roll). Some have full rotation on the X axis. A few examples with rotation ranges visualised:



The blue + red areas combined show the full movement range of the weapon, and the red areas show where it could move but it's currently blocked by something. It looks like it's doing an OK job of calculating those, but there are plenty of cases where my current solution falls apart.

I need to find the limits of where it can move. Some notes:

  • I don't want weapons to hit or shoot your own vehicle, so you can imagine the weapon barrel is essentially infinite length.
  • There are more complex solutions, but all I want is a reduced box for allowable movement - an adjusted Min X, Max X, Min Y and Max Y that take into account surrounding colliders on the vehicle.
  • All colliders to check against are AABB non-rotated box colliders.
  • You can assume all other parts are non-moving.
  • Sometimes there are multiple solutions where you can choose to reduce either X or Y to avoid something. I currently keep track of several options and at the end, take the solution with the biggest remaining area.

I've already tried solving this in different ways:

  • With raycasts. Relatively simple. Raycast a whole lot, evenly spaced at different angles, and reduce rotation range based on the hits. But I never managed to get a good tradeoff between accuracy and performance. It was either not accurate enough or not fast enough (game is in the Unity engine). I need to be able to update ranges on-the-fly.
  • Letting physics do it. Just put colliders on the weapon barrels and let them hit the vehicle and get stopped. This behaved in a janky way, wasted performance because I should be able to pre-calculate it, and didn't stop weapons shooting your own vehicle if the barrel missed something but a bullet didn't (extending the collider might do that but then I'd have to worry about other things hitting it etc).
  • Checking other colliders manually. This is what I'm doing now. Look at every other collider on the vehicle, with early exits where possible, and convert its position into angle limits, then reduce the max rotation range as necessary. This sounds kinda simple, but in practice it's been extremely complicated and difficult to get right, and I still have things that don't work because I'm not doing it perfectly.

Sorry for the wall of text. I feel like this is something that must have been done before, but I couldn't find any sources of information on it. It seems impossible to Google but it must have been done. Someone told me to look into robotics research, but I wouldn't know where to start. If we can send people to the Moon we must be able to reduce a rotation range based on some box colliders.

ToxicSlurpee
Nov 5, 2003

-=SEND HELP=-


Pillbug

HappyHippo posted:

This is the right approach but that particular algorithm can be problematic because it jumps along diagonals. For this situation you want something more like this: http://www.redblobgames.com/grids/line-drawing.html#stepping

True. That depends on if that is desirable behavior or not. I used that because the way I was generating levels at the time didn't have those "tiny crack between two diagonal walls" situations and I wanted the player to be able to see a square around corners.

That's a good link, though. Gonna read that.

ZombieApostate
Mar 13, 2011
Sorry, I didn't read your post.

I'm too busy replying to what I wish you said

:allears:

Nition posted:

Speaking of colliders and algorithms, one thing that's caused me endless headaches in my current game is calculating weapon movement ranges. Every weapon is a turret with some amount of X (pitch) and Y-axis (yaw) movement. Never any Z-axis (roll). Some have full rotation on the X axis. A few examples with rotation ranges visualised:



The blue + red areas combined show the full movement range of the weapon, and the red areas show where it could move but it's currently blocked by something. It looks like it's doing an OK job of calculating those, but there are plenty of cases where my current solution falls apart.

I need to find the limits of where it can move. Some notes:

  • I don't want weapons to hit or shoot your own vehicle, so you can imagine the weapon barrel is essentially infinite length.
  • There are more complex solutions, but all I want is a reduced box for allowable movement - an adjusted Min X, Max X, Min Y and Max Y that take into account surrounding colliders on the vehicle.
  • All colliders to check against are AABB non-rotated box colliders.
  • You can assume all other parts are non-moving.
  • Sometimes there are multiple solutions where you can choose to reduce either X or Y to avoid something. I currently keep track of several options and at the end, take the solution with the biggest remaining area.

I've already tried solving this in different ways:

  • With raycasts. Relatively simple. Raycast a whole lot, evenly spaced at different angles, and reduce rotation range based on the hits. But I never managed to get a good tradeoff between accuracy and performance. It was either not accurate enough or not fast enough (game is in the Unity engine). I need to be able to update ranges on-the-fly.
  • Letting physics do it. Just put colliders on the weapon barrels and let them hit the vehicle and get stopped. This behaved in a janky way, wasted performance because I should be able to pre-calculate it, and didn't stop weapons shooting your own vehicle if the barrel missed something but a bullet didn't (extending the collider might do that but then I'd have to worry about other things hitting it etc).
  • Checking other colliders manually. This is what I'm doing now. Look at every other collider on the vehicle, with early exits where possible, and convert its position into angle limits, then reduce the max rotation range as necessary. This sounds kinda simple, but in practice it's been extremely complicated and difficult to get right, and I still have things that don't work because I'm not doing it perfectly.

Sorry for the wall of text. I feel like this is something that must have been done before, but I couldn't find any sources of information on it. It seems impossible to Google but it must have been done. Someone told me to look into robotics research, but I wouldn't know where to start. If we can send people to the Moon we must be able to reduce a rotation range based on some box colliders.

You could probably simplify your problem by removing the restriction that you can't shoot yourself from your pre-calculation. Then you can raycast at runtime when the player tries to shoot and make it so any gun that would shoot your own vehicle just doesn't fire. Hell, let them shoot themselves and have a vehicle part that acts as a safety device that prevents shooting yourself.

Rocko Bonaparte
Mar 12, 2002

Every day is Friday!
Aren't there things like hingejoints you can use to have Unity enforce rotational constraints?

Granted, when I tried them for simple things like doors, I had all kind of crazy poo poo happen.

Sistergodiva
Jan 3, 2006

I'm like you,
I have no shame.

HappyHippo posted:

This is the right approach but that particular algorithm can be problematic because it jumps along diagonals. For this situation you want something more like this: http://www.redblobgames.com/grids/line-drawing.html#stepping

Wow thanks. This was actually surprisingly easy.

I think I'm going with the one that jumps diagonally, since I want to be able to shoot straight, but I could always change and test that later.



I feel like I actually learn more translating code from his (javascript?) to java, since I actually have to understand what I am doing.

Right now I am using scene2d MoveToActions for my movement, but I guess I could use stuff like this for smooth movement? Because right now I am having to add RunnableActions that detract from my actionPoints as I walk, to get the currentAP/maxAP display under the characters to update as they walk. Problem is, doing it my way gives me trouble trying to stop my enemies when they are adjacent to a player, so they can execute a melee attacks.

Warning, this is messy and I should probably not have the logic for enemies ending their turn in the movement code :P

code:
private void moveEnemy(List<GridCell> enemyPath, Enemy enemy) {
        SequenceAction multiMove = new SequenceAction();
        tmpMP2 = enemy.getCurrentAP();
        for (int i = 0; i < enemyPath.size(); i++) {
            if (tmpMP2 > i) {
                MoveToAction mta = new MoveToAction();
                mta.setPosition(enemyPath.get(i).getX() * 16, enemyPath.get(i).getY() * 16);
                mta.setDuration(0.2f);
                RunnableAction ra = new RunnableAction() {
                    @Override
                    public void run() {
                        tmpMP2--;
                        //enemy.setCurrentAP(tmpMP);

                    }
                };
                multiMove.addAction(ra);
                multiMove.addAction(mta);
            }
        }
        multiMove.addAction(new RunnableAction() {
            @Override
            public void run() {
                playerTurn = true;
                turnAnnounce.setText("Player turn: " + turnNumber);
            }
        });
        enemy.addAction(multiMove);
    }

Sistergodiva fucked around with this message at 07:43 on Feb 11, 2016

leper khan
Dec 28, 2010
Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

Nition posted:

Speaking of colliders and algorithms, one thing that's caused me endless headaches in my current game is calculating weapon movement ranges. Every weapon is a turret with some amount of X (pitch) and Y-axis (yaw) movement. Never any Z-axis (roll). Some have full rotation on the X axis. A few examples with rotation ranges visualised:



The blue + red areas combined show the full movement range of the weapon, and the red areas show where it could move but it's currently blocked by something. It looks like it's doing an OK job of calculating those, but there are plenty of cases where my current solution falls apart.

I need to find the limits of where it can move. Some notes:

  • I don't want weapons to hit or shoot your own vehicle, so you can imagine the weapon barrel is essentially infinite length.
  • There are more complex solutions, but all I want is a reduced box for allowable movement - an adjusted Min X, Max X, Min Y and Max Y that take into account surrounding colliders on the vehicle.
  • All colliders to check against are AABB non-rotated box colliders.
  • You can assume all other parts are non-moving.
  • Sometimes there are multiple solutions where you can choose to reduce either X or Y to avoid something. I currently keep track of several options and at the end, take the solution with the biggest remaining area.

I've already tried solving this in different ways:

  • With raycasts. Relatively simple. Raycast a whole lot, evenly spaced at different angles, and reduce rotation range based on the hits. But I never managed to get a good tradeoff between accuracy and performance. It was either not accurate enough or not fast enough (game is in the Unity engine). I need to be able to update ranges on-the-fly.
  • Letting physics do it. Just put colliders on the weapon barrels and let them hit the vehicle and get stopped. This behaved in a janky way, wasted performance because I should be able to pre-calculate it, and didn't stop weapons shooting your own vehicle if the barrel missed something but a bullet didn't (extending the collider might do that but then I'd have to worry about other things hitting it etc).
  • Checking other colliders manually. This is what I'm doing now. Look at every other collider on the vehicle, with early exits where possible, and convert its position into angle limits, then reduce the max rotation range as necessary. This sounds kinda simple, but in practice it's been extremely complicated and difficult to get right, and I still have things that don't work because I'm not doing it perfectly.

Sorry for the wall of text. I feel like this is something that must have been done before, but I couldn't find any sources of information on it. It seems impossible to Google but it must have been done. Someone told me to look into robotics research, but I wouldn't know where to start. If we can send people to the Moon we must be able to reduce a rotation range based on some box colliders.

Your problem is basically a textbook inverse kinematics problem for a robot with a fixed length end effector with two rotational degrees of freedom. Too much :effort: to bother to find my old robotics notes, but that's what you want to google.

E: forward kinematics; I thought you wanted to aim the turrets automatically for some reason.

leper khan fucked around with this message at 08:18 on Feb 11, 2016

Nition
Feb 25, 2006

You really want to know?

ZombieApostate posted:

You could probably simplify your problem by removing the restriction that you can't shoot yourself from your pre-calculation. Then you can raycast at runtime when the player tries to shoot and make it so any gun that would shoot your own vehicle just doesn't fire. Hell, let them shoot themselves and have a vehicle part that acts as a safety device that prevents shooting yourself.

Weapons would still clip with stuff on the vehicle though. :(

Rocko Bonaparte posted:

Aren't there things like hingejoints you can use to have Unity enforce rotational constraints?

Granted, when I tried them for simple things like doors, I had all kind of crazy poo poo happen.

Yeah, but if I'm specifying limits on joints, then I still have to calculate the limits. It is possible to have a physics-based solution, but I already have too much physics calculation going on and it's also nice to have stuff like the movement previews in the screenshots above, which I wouldn't be able to do.

leper khan posted:

Your problem is basically a textbook inverse kinematics problem for a robot with a fixed length end effector with two rotational degrees of freedom. Too much :effort: to bother to find my old robotics notes, but that's what you want to google.

Thanks, I'll try some more searches.

Rocko Bonaparte
Mar 12, 2002

Every day is Friday!
The past few pages of this thread and the past few pages of my personal notes taught me games are collision detection. I was trying to figure out how to test colliding along a plane in Unity, and fell back on thin boxes . . . I think.

Nude
Nov 16, 2014

I have no idea what I'm doing.

Rocko Bonaparte posted:

The past few pages of this thread and the past few pages of my personal notes taught me games are collision detection. I was trying to figure out how to test colliding along a plane in Unity, and fell back on thin boxes . . . I think.

Two things that I have noticed for every time I make a game is:

How I handle collision detection often dictates the "coding structure" of my games. And all games boil down to conditions.

Zaphod42
Sep 13, 2012

If there's anything more important than my ego around, I want it caught and shot now.

Sistergodiva posted:

Wow thanks. This was actually surprisingly easy.

I think I'm going with the one that jumps diagonally, since I want to be able to shoot straight, but I could always change and test that later.



Make sure you check for the case that website he linked shows though. If you're jumping diagonally then you can effectively shoot through solid walls if the walls are diagonal and not vertical or horizontal. If you don't want to be able to shoot through diagonal walls, you need to use the other algorithm he linked.

If there's never a situation in your game where you'll have two diagonal walls without having the corner also filled in, then you're fine, but if that's something that could happen you should check for it.

Inverness
Feb 4, 2009

Fully configurable personal assistant.

Nition posted:

  • With raycasts. Relatively simple. Raycast a whole lot, evenly spaced at different angles, and reduce rotation range based on the hits. But I never managed to get a good tradeoff between accuracy and performance. It was either not accurate enough or not fast enough (game is in the Unity engine). I need to be able to update ranges on-the-fly.
Wouldn't the need for raycasting stop once you've found the limits of where the turret could move? You could then just save the valid angles until the next time the turret is changed.

I assume "on-the-fly" means you can change turrets in the game, but not that its happening every frame or something.

Inverness fucked around with this message at 16:14 on Feb 11, 2016

Quaternion Cat
Feb 19, 2011

Affeline Space
edit haha ^^^ just said the same thing.

Nition posted:


  • With raycasts. Relatively simple. Raycast a whole lot, evenly spaced at different angles, and reduce rotation range based on the hits. But I never managed to get a good tradeoff between accuracy and performance. It was either not accurate enough or not fast enough (game is in the Unity engine). I need to be able to update ranges on-the-fly.

When you say you need to do this on the fly, what do you mean? Surely you only need to run this calculation whenever your car's body changes, and then you'd know the maximum pivot angles for each gun and could just retain those as floats and clamp any attempts for the gun to aim at beyond those until the car changed again? How you'd end up doing that probably depends a great deal on if you're doing your own trigonometry to aim them or relying on quaternion methods to aim at targets, but both methods'll have ways to clamp them.

In fact, based on how you can bolt these guns to different parts of your car, and, the ones to be limited are all going to have straight barrels stuck to them, do you ever in fact ever really have to calculate these values on a per barrelled gun basis? You'd think all these barrelled guns would share the same maximum arc range per slot. I'm sure you've thought about that and concluded that you need to do this, it just seems like a surprising result to me. Maybe it's due to when you have far fewer guns vs bristling with them?

Xerophyte
Mar 17, 2008

This space intentionally left blank

Nition posted:

Checking other colliders manually. This is what I'm doing now. Look at every other collider on the vehicle, with early exits where possible, and convert its position into angle limits, then reduce the max rotation range as necessary. This sounds kinda simple, but in practice it's been extremely complicated and difficult to get right, and I still have things that don't work because I'm not doing it perfectly.

This seems sensible me, it's essentially just projecting the 8 vertices of each collider to spherical coordinate angles and subtracting a hull that contains them from the valid range, right? What are the complications? Just that it's not a tight bound? I guess you'd also need to subdivide any collider that is directly above or below, and mind azimuth wraparound but it seems manageable...

Rocko Bonaparte
Mar 12, 2002

Every day is Friday!

Xerophyte posted:

This seems sensible me, it's essentially just projecting the 8 vertices of each collider to spherical coordinate angles and subtracting a hull that contains them from the valid range, right?
It did occur to me personally that it sounded like a boolean subtract or whatever it is in one's modeling tool of choice, but I have no drat clue how those algorithms work.

Nition
Feb 25, 2006

You really want to know?

Mastigophoran posted:

edit haha ^^^ just said the same thing.


When you say you need to do this on the fly, what do you mean? Surely you only need to run this calculation whenever your car's body changes, and then you'd know the maximum pivot angles for each gun and could just retain those as floats and clamp any attempts for the gun to aim at beyond those until the car changed again? How you'd end up doing that probably depends a great deal on if you're doing your own trigonometry to aim them or relying on quaternion methods to aim at targets, but both methods'll have ways to clamp them.

In fact, based on how you can bolt these guns to different parts of your car, and, the ones to be limited are all going to have straight barrels stuck to them, do you ever in fact ever really have to calculate these values on a per barrelled gun basis? You'd think all these barrelled guns would share the same maximum arc range per slot. I'm sure you've thought about that and concluded that you need to do this, it just seems like a surprising result to me. Maybe it's due to when you have far fewer guns vs bristling with them?

Vehicles can lose parts in-game, which often means the movement range needs re-calculating on some weapons (I only recalculate if specific parts that were blocking the weapon are lost). Vehicles can get pretty complex and Unity's raycasts are petty slow. To get a decently accurate result on a full turret weapon, raycasting 3 degrees apart say can take 10+ms per weapon, which is too much. The collider checking method is much faster (more like 1ms if that).

The same weapon will always have the same base movement range, but I'm calculating places where it can't aim due to other stuff in the way, which can be in all sorts of configurations. You can place a weapon on your vehicle in any spot as long as it can shoot straight ahead - it's not like Robocraft where the full movement range of the weapon has to be free.

Xerophyte posted:

This seems sensible me, it's essentially just projecting the 8 vertices of each collider to spherical coordinate angles and subtracting a hull that contains them from the valid range, right? What are the complications? Just that it's not a tight bound? I guess you'd also need to subdivide any collider that is directly above or below, and mind azimuth wraparound but it seems manageable...

It's highly likely that I'm making this method more complicated than necessary due to having to work out a solution myself. It's easy to say "just subtract the colliders from the range" but the maths involved kills me. Certainly it's gotta be like a type of boolean subtract, but like Rocko Bonaparte said although I know what that is I haven't managed to work out how to actually do it here. Especially since this isn't really comparing shapes against a shape, but more like comparing shapes against one infinite-radius chunk of a sphere.

Polio Vax Scene
Apr 5, 2009



Nition posted:

Vehicles can lose parts in-game, which often means the movement range needs re-calculating on some weapons (I only recalculate if specific parts that were blocking the weapon are lost).

I don't think this is that big of a deal if you don't recalculate. It actually sounds kind of unintuitive. You wouldn't put weapons on a vehicle with the intent of gaining more motion in them by losing parts during the game.

Nition
Feb 25, 2006

You really want to know?
Yeah I thought about it, but it's kinda dumb if you don't get the extra movement when you lose parts around it. Besides I do have it working with decent performance, I'd just like to improve my janky code that's not always quite right with the results.

leper khan
Dec 28, 2010
Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

Nition posted:

Vehicles can lose parts in-game, which often means the movement range needs re-calculating on some weapons (I only recalculate if specific parts that were blocking the weapon are lost). Vehicles can get pretty complex and Unity's raycasts are petty slow. To get a decently accurate result on a full turret weapon, raycasting 3 degrees apart say can take 10+ms per weapon, which is too much. The collider checking method is much faster (more like 1ms if that).

The same weapon will always have the same base movement range, but I'm calculating places where it can't aim due to other stuff in the way, which can be in all sorts of configurations. You can place a weapon on your vehicle in any spot as long as it can shoot straight ahead - it's not like Robocraft where the full movement range of the weapon has to be free.


It's highly likely that I'm making this method more complicated than necessary due to having to work out a solution myself. It's easy to say "just subtract the colliders from the range" but the maths involved kills me. Certainly it's gotta be like a type of boolean subtract, but like Rocko Bonaparte said although I know what that is I haven't managed to work out how to actually do it here. Especially since this isn't really comparing shapes against a shape, but more like comparing shapes against one infinite-radius chunk of a sphere.

Comedy answer:
Bake in the N-dimensional manifold of range-per-weapon-per-potential-blocker and just lookup the index at run time.
Then just calculate the manifold by iterating all potential inputs and flagging bad intersections. Thereby circumventing all maths.

Nition
Feb 25, 2006

You really want to know?
Since I want to avoid all maths with that approach, I'll just set up an interface where the game presents me with each blocker set and I then manually drag the appropriate limits. Surely there won't be too many possibilities! ;)

Obsurveyor
Jan 10, 2003

Nition posted:

Since I want to avoid all maths with that approach, I'll just set up an interface where the game presents me with each blocker set and I then manually drag the appropriate limits. Surely there won't be too many possibilities! ;)

Are the parts that make up a vehicle all based on a standard unit size? If so, based on what block units are filled in or not around the weapon, you should be able to limit it that way. It's not polygon perfect but I bet no one would notice.

Nition
Feb 25, 2006

You really want to know?
Nah, there are realistically way too many combinations. Although things generally snap in a grid, their colliders can be in various places. And it's quite cool as a feature how you can have guns going through small gaps.

Futuresight
Oct 11, 2012

IT'S ALL TURNED TO SHIT!

Nition posted:

Yeah I thought about it, but it's kinda dumb if you don't get the extra movement when you lose parts around it. Besides I do have it working with decent performance, I'd just like to improve my janky code that's not always quite right with the results.

If recalculation is the problem, couldn't you calculate at build time the spots that would be opened up if a part was removed? At worst you could calculate the shootable area, then remove a part and calculate the differences, and then repeat for each part that could matter. Then just use that data whenever a part is removed during actual gameplay.

Lork
Oct 15, 2007
Sticks to clorf

Nition posted:

ZombieApostate posted:

You could probably simplify your problem by removing the restriction that you can't shoot yourself from your pre-calculation. Then you can raycast at runtime when the player tries to shoot and make it so any gun that would shoot your own vehicle just doesn't fire. Hell, let them shoot themselves and have a vehicle part that acts as a safety device that prevents shooting yourself.
Weapons would still clip with stuff on the vehicle though. :(
They're saying that you should do that instead of assuming the barrels are infinite length, not instead of doing collision at all. I agree, and not just because it simplifies the problem, but because you'll avoid situations where a turret has to turn almost 360 degrees to hit a target that is 10 degrees off because it refuses to traverse a space that it would otherwise be able to fit through.

Nition
Feb 25, 2006

You really want to know?
I'm pretty happy with how it works now and I'd prefer not to change how the game works if I can help it, I'd rather just get my formula right. Currently I'm trying something like a n00b version of Xerophyte's suggestion.

Polio Vax Scene
Apr 5, 2009



The worst bugs are when something just won't draw, because no matter what you change you aren't getting any feedback.
Is it the coordinates?
Is it the camera matrix?
Is the shader messing something up?
Am I missing a texture or drawing with 0 alpha??
Are my polys backward??
Nope, being clipped by z culling. 2 hours of poking around to be fixed by changing one variable.

HappyHippo
Nov 19, 2003
Do you have an Air Miles Card?

Nition posted:

I'm pretty happy with how it works now and I'd prefer not to change how the game works if I can help it, I'd rather just get my formula right. Currently I'm trying something like a n00b version of Xerophyte's suggestion.

How much computation does it take to test a single ray against the vehicle's components? Because if it isn't long then instead of precalculating the acceptable range of angles you can just test as the turret is rotated - check the ray of what would be the new position, and if it collides then reject the rotation. You'd be doing at most one test per frame per turret.

Nition
Feb 25, 2006

You really want to know?

HappyHippo posted:

How much computation does it take to test a single ray against the vehicle's components? Because if it isn't long then instead of precalculating the acceptable range of angles you can just test as the turret is rotated - check the ray of what would be the new position, and if it collides then reject the rotation. You'd be doing at most one test per frame per turret.

Yeah, this one would be doable I think. Although I do like being able to show the available range when the vehicle is being built - it helps people design.

Ralith
Jan 12, 2011

I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today

Nition posted:

Yeah, this one would be doable I think. Although I do like being able to show the available range when the vehicle is being built - it helps people design.

You should be able to get what you want by using a variation on techniques used to implement dynamic shadow mapping for point lights. I'm not an expert on those, but for example, you might start by projecting vertices that lie on boundaries between solid and void away from the center of rotation of the turret, and rendering the faces between the original vertices and projected vertices, with a fragment shader culling fragments further than a certain radius away from the turret.

Nition
Feb 25, 2006

You really want to know?

Ralith posted:

You should be able to get what you want by using a variation on techniques used to implement dynamic shadow mapping for point lights. I'm not an expert on those, but for example, you might start by projecting vertices that lie on boundaries between solid and void away from the center of rotation of the turret, and rendering the faces between the original vertices and projected vertices, with a fragment shader culling fragments further than a certain radius away from the turret.

It'd be awesome to do the calculation on the GPU with a shader but possibly beyond my skills. It has certainly been interesting how asking a "simple" maths question of how to reduce rotation to avoid collisions has gotten me suggestions relating to robotics, 3D modelling, graphics work, etc.

roomforthetuna
Mar 22, 2005

I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Nition posted:

It'd be awesome to do the calculation on the GPU with a shader but possibly beyond my skills. It has certainly been interesting how asking a "simple" maths question of how to reduce rotation to avoid collisions has gotten me suggestions relating to robotics, 3D modelling, graphics work, etc.
This is what makes game development awesome. You get to do all the difficult things that serious computer scientists do, but you're doing it under horrible hardware constraints and just for fun!

Sistergodiva
Jan 3, 2006

I'm like you,
I have no shame.

roomforthetuna posted:

This is what makes game development awesome. You get to do all the difficult things that serious computer scientists do, but you're doing it under horrible hardware constraints and just for fun!

I like it when you realize the algorithm you need was invented in the 60s or whatever.

OneEightHundred
Feb 28, 2008

Soon, we will be unstoppable!

roomforthetuna posted:

This is what makes game development awesome. You get to do all the difficult things that serious computer scientists do, but you're doing it under horrible hardware constraints and just for fun!
I disagree, what makes game development awesome is all of the things that serious computer scientists don't do, like deal with the fact that everything in the game capable of moving will, at some point in development, be launched into the stratosphere by a physics bug.

Adbot
ADBOT LOVES YOU

leper khan
Dec 28, 2010
Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

OneEightHundred posted:

I disagree, what makes game development awesome is all of the things that serious computer scientists don't do, like deal with the fact that everything in the game capable of moving will, at some point in development, be launched into the stratosphere by a physics bug.

I've talked with scientists who launch capable humans into the stratosphere. Games are awesome because our physics bugs make me chuckle, and their physics bugs do not.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply