#Optic Physics

1 messages · Page 1 of 1 (latest)

indigo sage
#

To not interrupt

#

@glossy carbon

#

here

#

Pretty much you need a phys sim running alongside MC and it needs to be fed:

  • Blocks
  • Entities
#

Then you want to "spawn" a structure of points based on the things you want to rotate/move

#

then try to conform the shape & pos of the display entity to that structure

glossy carbon
#

We'd need some way to set weight for each block material, e.g. glass a low weight and obsidian a high one.

Making sure building and stuff is still possible is another problem as well

indigo sage
#

I mean yeah it would be

#

Display entities don't have an hitbox, you can place in them iirc

glossy carbon
#

Ehh, placing would also have to be affected by physics as well, considering ya know, minecraft

indigo sage
#

fair

indigo sage
glossy carbon
#

world gen can be ignored for performance reasons (and to ya know, not require a custom world gen LMAO)

indigo sage
#

Yeah

#

So I guess if you build too far out it'll fall?

glossy carbon
#

or cause a chunk to fall, depending on weight

indigo sage
#

An entire chunk DAMN

glossy carbon
#

e.g. a block of gold on a pillar of wood, makes no sense if only the gold fell

indigo sage
#

yeah

#

Though there is the problem of making chunks from blocks (or you can use the full model ig)

glossy carbon
#

Would need some sort of limit on that as well, unless affected by the falling blocks themselves

indigo sage
#

@glossy carbon type exactly what you want beacuse I am not getting some parts lmao

glossy carbon
#

e.g. if the wood pillar's 19 blocks tall and the gold block makes it 20, you don't want to have all 20 blocks do physics calculations

  1. Performance
  2. Realistically only so much of it would fall anyways
#

We do get to cut corners though, considering most things are the same size however

indigo sage
glossy carbon
#

context: https://www.youtube.com/watch?v=GJU_P3tnf3A

Instead of only gravity blocks having physics (sand, gravel, red sand, etc) every block would have physics.

World gen would not have physics applied to it, for performance reasons and to allow generation to happen properly (e.g. a city generator). Outside of that, it would more or less function as a regular physics engine.

#

*modifications to take into account Minecraft gameplay of course

#

Physics would be handled on break/place (affecting both world gen & player placed blocks)

#

Did just realize we need some way to calculate if a specific block should have physics applied to it or not and that can kinda get complex

#

e.g. The dimand block would not cause anything to fall, considering the netherite is "heavier" than the diamond block

image.png
#

however in this case, it should fall since nothing's really holding it in place (though ig we'd need some sort of impl to make that possible)

image.png
glossy carbon
indigo sage
#

Ah

glossy carbon
#

Although an engine which cuts corners there would still be useful e.g. mini games

indigo sage
#

I've tried to do that before but it was a mess, I had no clue about light updates lmao

glossy carbon
#

Lmao

indigo sage
glossy carbon
#

Tldr; realistic as possible, while still allowing vanilla gameplay. Unless specifically designed for say, mini games

indigo sage
#

Yeah

glossy carbon
indigo sage
#

Yeah

glossy carbon
#

e.g. if you took out an entire floor of a building, it wouldn't all go straight down, but all over the place depending on each block and its attributes

indigo sage
#

yea

#

I can check once I am back, I got some ideas

#

though I need to go or I'll miss the bus

glossy carbon
#

Could do an editing/building mode, where physics doesn't get applied

indigo sage
#

nah

glossy carbon
#

I was thinking more for spawn, arena, etc building

indigo sage
#

ah I guess

#

Well if you want @glossy carbon I can take care of the phys engine

glossy carbon
#

👍

glossy carbon
indigo sage
#

Ah

glossy carbon
#

base engine first, expand off that

indigo sage
#

Yep, I am currently gathering some resouces for you to learn from then

#

Because whilst verlet may be cheap and easy, it's not always the best documented lmao

glossy carbon
#

kek

glossy carbon
indigo sage
#

Yep

#

I suggest the following steps:

  • Dots
  • Dot Gravity
  • Sticks (Restraint between two dots)

And now you have falling & rotation & shapes

Then:

  • Collision detection
  • Collision resolution

And you now have a rudimentary physics engine

Optionally, you can define a series of Dots & Sticks as a "Shape", which you can calculate it's rotation and overall velocity from by getting it's center of mass, taking the top-right most point, and calculating the angle from Vector.UP and that point, taking as an origin the center of mass

glossy carbon
#

Just realized handling tnt will be fun, due to explosion radius

indigo sage
#

Ah yeah explosions

#

you can most likely get all points in that radius and give them a velocity lol

glossy carbon
#

You'd still need to do math to calculate the effectiveness though, since it would drop off the further away from the explosion it is

indigo sage
#

dot.position.subtract(explosion.position)

#

Actually that's the force you need to apply

glossy carbon
#

I wonder if there's any open source physic engines we can ste-take ideas from 🤔

indigo sage
#

Yeah Box2D is OS but in C++

#

and is quite complex

glossy carbon
#

more in terms of functionality, saves us time from having to do actual research kek

indigo sage
#

I am just researching collision handling tbh

glossy carbon
#

There's quite a few on github in Java alone, and while incredibly unlikely to be copy-paste, miiiight have implementations for specific things

#

Particles would be a fun one to figure out, though I don't think there's any way to detect if they hit anything which means constant checking per-particle

indigo sage
#

so particles would simply be dots with a certain velocity

#

so yes, they would have collision

glossy carbon