orient particle to specific axis: Page 4

orient particle to specific axis

DJM

@xyz said: Umm... there should be a look_at() call somewhere. Anyway, here's a version that operates in local space so it properly handles decals attached to moving objects. In the below demo both - the camera and the object - are moving. Make sure your particle node emits in local space (Particles.local_coords) and that particle shader's Local to Scene flag is enabled (Resource.resource_local_to_scene)

strange, same result. particle spawn to the right wherever i look

xyz

Don't really know what you mean by "spawn to the right".

Make sure the sequence of calls is the same as in the demo and that you use the latest shader code.

DJM

there must be something wrong in the raycast function. it doesnt get the correct normal vector i think


func firebullet():
	self.force_raycast_update()
	#print(maincam.name)
	if self.is_colliding():
		var collider = self.get_collider()
		var impact = impact_normal.instance()
		
		
		var n = self.get_collision_normal()
		var p = self.get_collision_point()
		
		collider.add_child(impact)
		
		
		impact.global_transform.origin = p
		impact.look_at(impact.to_local(n), Vector3.UP)
		impact.forward = Vector3(0.0, 0.0, 1.0)
		impact.cam = maincam
		
		
		
		if collider is RigidBody:
			
			collider.apply_impulse( p - collider.transform.origin ,- self.global_transform.basis.z * force)

xyz

My code assumes that particle system doesn't have any transformations in respect to its parent. So make sure this is so. Try to put something like my arrow into impact to check if it gets oriented properly.

DJM

no , it doesnt get oriented properly i have no idea why

DJM

it always points somewhat to the right(world space)

xyz

In line 16 try:

impact.look_at_from_position(p, p - n, Vector3.UP)

cybereality

I found collision normal to be unreliable. Collision point is always correct, but the normal can be far off, unless it is on a large flat object. I've worked around this by getting the collision point (which is always correct) and using look_at.

xyz

This was overlook on my side. I didn't take into account the fact that look_at() operates in global space, so demo worked fine when collider was situated at the origin (even if it rotates), but if it has any translations then the vector ends up being wrong. The last correction should fix it. The demo now works as expected with any transformations on the collider (except non-proportional scaling).

DJM

@cybereality said: I found collision normal to be unreliable. Collision point is always correct, but the normal can be far off, unless it is on a large flat object. I've worked around this by getting the collision point (which is always correct) and using look_at.

actually u r right, i did some tests and the collision normal doesnt seem to be reliable. how do u use the lookat based on collisionpoint only?

DJM

@xyz said: In line 16 try:
impact.look_at_from_position(p, p - n, Vector3.UP)
doesnt give a reliable result. the particle still spawns to the right of the camera view there must be something wrong with collision normal calculation

xyz

I really don't see a reason for engine to screw up the ray hit normal reporting. That would be quite a serious flaw on its part. If it really happens, it needs immediate attention. Make a minimal reproduction project and report the thing to devs.

What is your collision shape? Is collision object (or any of its parents) non-proportionally scaled? Can we see some images/videos that show the problem? Try to put your collider into my demo and see what happens. I tried with different types of shapes and returned hit normal always appears to have the expected direction. It's the same for either Area or RigidBody collision object.

Megalomaniak

Pretty sure it's a known issue with bullet specifically.

xyz

I used Bullet before (via C++ api) but didn't encounter the issue. There could be some misbehavior with body vs body collision normals, however with straightforward things like raycasts, that would really be strange. So what happens when you switch to GodotPhysics in the project settings (under Physics/3d), @DJM ?

cybereality

Yeah, it seems like a serious error, but I found it didn't work all the time. However, this was when I first started using Godot a few years ago, so maybe it has been fixed or I was doing something wrong. The issue specifically was on edges. If you hit a large flat object like a cube in the middle, then the normal would be correct. But on more complex objects around edges the normal would warp in strange unpredictable ways. For some visual effects this may be good enough (like debris coming off gun fire, etc.). But if you need accurate results for the gameplay it was not good enough. I'll double-check when I have a second to see if it still happens. In any case, I doubt anyone will fix it, as Godot 4.0 is switching to GodotPhysics, so I don't think Bullet is getting updated (but for something as important as this maybe they will make an exception).

DJM

i have absolutely no idea why my decals dont get oriented correctly, remember, im a rookie coder tried setting physics to godot same result.

heres my raycast script

extends RayCast

export(PackedScene) var impact_normal
export var force = 20.0
export var damage = 50.0
export (NodePath) var maincamera_path
onready var maincam = get_node(maincamera_path)


func firebullet():
	self.force_raycast_update()
	#print(maincam.name)
	if self.is_colliding():
		var collider = self.get_collider()
		var impact = impact_normal.instance()
		
		
		var n = self.get_collision_normal()
		var p = self.get_collision_point()
		
		collider.add_child(impact)
		
		
		
		impact.global_transform.origin = p
		impact.look_at_from_position(p, p - n, Vector3.UP)
		impact.forward = Vector3(0.0, 0.0, 1.0)
		impact.cam = maincam
		
		
		
		if collider is RigidBody:
			
			collider.apply_impulse( p - collider.transform.origin ,- self.global_transform.basis.z * force)

and my decal script

extends Spatial

export (AudioStreamSample) var impactsound 
export(NodePath) var particles1_path
export(NodePath) var particlesStretched_path
export(NodePath) var myaudio_path
export(NodePath) var decalprojector_path
export var stretchedparticleScale : Vector2 
export var decalmaxSize = 0.1
export var decalminSize = 0.05
onready var decalprojector = get_node(decalprojector_path)
onready var particles1 = get_node(particles1_path)
onready var particlesStretched = get_node(particlesStretched_path)
onready var myAudio = get_node(myaudio_path)
var cam = null
var forward: Vector3

var random = RandomNumberGenerator.new()

func _ready():
	
	add_to_group("ignore")
	random.randomize()
	var randomscale = random.randf_range(decalminSize, decalmaxSize)
	decalprojector.scale = Vector3(randomscale,randomscale,randomscale)
	addDecal()

func addDecal():
	myAudio.stream = impactsound
	myAudio.pitch_scale = random.randf_range(0.9, 1.1)
	if myAudio.playing  == false:
		myAudio.play()
	particles1.set_one_shot(true)
	particles1.set_emitting(true)
	particlesStretched.set_one_shot(true)
	particlesStretched.set_emitting(true)
func _process(_delta):
	particlesStretched.process_material.set_shader_param("campos", particlesStretched.to_local(cam.global_transform.origin))
	particlesStretched.process_material.set_shader_param("forward", forward)
	particlesStretched.process_material.set_shader_param("decalScale", stretchedparticleScale)
	
	

func _on_VisibilityNotifier_camera_exited(_camera):
	self.queue_free()

the console does print this error tho

DJM

@xyz said: I really don't see a reason for engine to screw up the ray hit normal reporting. That would be quite a serious flaw on its part. If it really happens, it needs immediate attention. Make a minimal reproduction project and report the thing to devs.

What is your collision shape? Is collision object (or any of its parents) non-proportionally scaled? Can we see some images/videos that show the problem? Try to put your collider into my demo and see what happens. I tried with different types of shapes and returned hit normal always appears to have the expected direction. It's the same for either Area or RigidBody collision object.

im using trimmesh static colliders for the environment

xyz

@cybereality I doubt this is the issue here, but I could we wrong. Simply switching to GodotPhysics can tell us whether it's this or something else. I'm guessing it's space-to-space transformations again.

But I agree that Bullet is a strange beast. Switching to default custom engine for 4.0 is a good decision, assuming the engine is well done.

xyz

@DJM said: the console does print this error tho

Try using some other up vector instead of Vector3.UP. You can start with Vector3.RIGHT. Ideally you should check if up vector is close to desired look vector and then use some other vector for the up direction. If these two vectors coincide, cross products inside look_at() will fail giving out the error and/or incorrect results.

DJM

@xyz said:

@DJM said: the console does print this error tho

Try using some other up vector instead of Vector3.UP. You can start with Vector3.RIGHT. Ideally you should check if up vector is close to desired look vector and then use other vector. If these two vector coincide, cross products inside look_at() will fail giving out the error and/or incorrect results.

Vector3.right makes the decals instantiate correctly, tnx! however the stretched particle still gets alligned to the right of the camera

dont know if its of any use but here s my node setup

« Previous Page Next Page »