Particles against the wall

[Ats]

Hi, I have a little question about particles and ZGE logic.

I'm firing lasers against a wall, which is a simple cube. When the laser hits the wall, I'm creating an explosion with particles. How can I know the Rotation of the generated 2D particles for making them facing the side of the cube that has been hit ?
Is it something as simple as a checkbox that I didn't find? Or do I have to calculate complicated things? And if it's complicated, would it be better to generate 2 faces of particles like for those trees?



I must precise that my particle emmiter is in the onCollision of the Laser, and that there is going to be a lot fo particles...

Thanks


Edit: Sorry, I opened many tabs to search for info in the forum and I didn't pay attention to where I was posting. I was sure I was in the "General discussion", wondering why there wasn't an "Help" forum ...

[Kjell]

Hi Ats,

ZGameEditor doesn't have raycasting build-in ( which is generally what you want for a laser ) and it doesn't return information on the intersection point either. However, depending on your situation the involved math can be quite easy. Three important factors:

- Since you mention "cube" i assume you're dealing with a laser that can be oriented in 3D?
- Is the cube axis-aligned or rotated?
- Will there be only one cube or multiple?

Perhaps you could explain what you're trying to create? That would make it allot easier to help you out

K

[Ats]

You're right

• So the laser is oriented in X and Z depending on the player/camera direction
• The cube is axis-aligned
• The walls are made of several cubes

I started my project with the FpsDemo which comes with ZGE. It has been modified a lot. There can be up to 4 players/cameras, so the solution I found to make the particles visible to everyone is to make them oriented with the wall's face that was hited.

[Kjell]

Hi Ats,

I started my project with the FpsDemo which comes with ZGE.

The FPS example that comes with ZGE isn't what you want to use ( in my opinion ) for a Wolfenstein / Rise of the Triad esque FPS. It's much faster / better to use grid-based levels instead of axis-aligned cubes.

And even if you don't want to use a grid ( for whatever reason ), you might still want to use some kind of spatial hashing ( depending on the complexity of your levels ). How many cubes do you anticipate to use per level?

There can be up to 4 players/cameras, so the solution I found to make the particles visible to everyone is to make them oriented with the wall's face that was hited.

If the particles should represent volumetric fragments, you can simply "rotate" them each render pass to match the viewport orientation

K

[Ats]

There is only one small level. Which looks a bit like Pac-Man's :

Let's say... 128 cubes.

I'll search for grid examples in the forum. Maybe there is one in particular that could help me understanding how it works.

you can simply "rotate" them each render pass to match the viewport orientation

You're totally right. I didn't think of that. Thanks!

[Ats]

So I thought that adding

Code: Select all

CurrentModel.Rotation.X = 0-App.CameraRotation.X;
CurrentModel.Rotation.Y = 0-App.CameraRotation.Y;

in the OnUpdate or OnRender of the particle model was enough but it's not the case. There is a lot of things I still don't understand about ZGE... Is it working in that order ?

1: OnUpdate (particle)
2: OnBeginRenderPass
3: OnRender (particle)

Because if I change the Rotation in OnRender, it seems to be updated in the next frame.

So do I have to retrieve each particles in the OnBeginRenderPass to make them face the camera ?

[Kjell]

Hi Ats,

You ( generally ) want to re-orient particles to the current camera in the OnRender event. Only OnBeginRenderPass and OnRender are executed multiple times when using multiple passes, whereas OnUpdate always executes only once per frame. However, since the model matrices are calculated before the OnRender event, when you update the rotation by changing CurrentModel.Rotation in OnRender, it won't have any effect until the next frame. You need to use a RenderTransform component instead

By the way, using a Model for each individual particle isn't a very good idea performance wise ( as pointed out previously in this thread ), but you can always solve that later.

K

[VilleK]

Hi Ats,

I've moved this topic to "General discussion".

Please post whatever you make of this project later, even if you don't finish it. Sounds interesting!

/V

[Ats]

Thanks Ville.
I'm going to create a topic about the game I'm working on once I'll get past all those little problems

[Kjell]

Since i promised to Ats i'd post this example publicly once he didn't have any questions anymore ( and since i haven't heard from him in a while, i guess he doesn't ), attached is a basic example of collision & raycast for a Wolfenstein style game.

In case somebody else does have any questions, let me know.

K

[VilleK]

Good example Kjell! I'm sure it can be useful for others.

[jph_wacheski]

Nice example Kjell. I just wrote (hacked from net examples) a line-of-sight script for an AI using an array for the level data,. I will check your code and see if I can understand it,. perhaps incorporate it.

I am building a game with a very simple destructible level stored in an array like this. I generate one mesh for all the "terrain" so I had to build my own object vs array collisions, rather basically,. but it does what is needed for the game.

I will post a demo shortly, once the basic gameplay is working well enough to show the idea.

[Ats]

Hi Kjell, sorry for the late response... I had to handle a combo of life events recently. But I'm back!
I'm going to dig your Raycast example and see if I can adapt my little game to it.

And thanks for the time you spent on it. I'm sure it'll be helpful for others too