(removed)

[raspberrypuppies]

(removed)

[vjbone]

Great art

[raspberrypuppies]

(removed)

[raspberrypuppies]

(removed)

[raspberrypuppies]

(removed)

[Klonan]

I'm losing my mind trying to set muzzle locations for guns. It's madness.

What part are you having trouble with? Can you provide some details?

Also these models look great, might be tempted to make a mod using them

[raspberrypuppies]

It would be an honor to have you make a mod with them.

I have had three main challenges:

1. Every single entity uses a different magic formula for calculating the muzzle offsets. It is not just that each AttackParameters works (drastically) differently. There are even differences between turret types (ammo turret vs artillery for example). One oddity is how each AttackParameters type has a different way of allowing "right handed" weapons. Projectile and Stream AttackParameters even support double-barreled weapons if you feed them weird projectile_creation_parameters.

2. I cannot figure out the right formula to translate either 2D sprite coordinates or 3D model coordinates to Factorio coordinates. It seems like some prototype offset fields prefer ortho 45 degree-based sprite values and others prefer top-down Factorio coordinates. As far as I can tell, some try and fix the weird perspective and others don't. Car dust, smoke, and headlights for example seem to prefer raw 3D points transformed into 2D space. But ammo-turrets seem to take the turret texture's shift values into account when setting the muzzle position. So you need to need find what pixel the muzzle is at in the turret texture to set ammo-turret positions correctly.

3. If I was a sane person I could just guess and check to find the right values. But my pipeline renders everything in several resolutions to make them more mod-agnostic. The RP Art code picks the best resolutions for the entity based on its game size. This means I need to do math to convert the rendered "attach points" in my code to whatever coordinate space Factorio expects at the time. As soon as I think I have figured out the formula I try 2x ing the sprite scale and see the small inaccuracies blown wildly out of proportion.

I've thought about trying to modify the render camera's projection matrix to stretch everything to compensate for the weird perspective but I don't know what magic incantation would do the trick. Maybe I just need to scale everything non-uniformly.

I've spent an unreasonable amount of time trying to figure this out. Like well over 160 hours. I bet money that I got confused and went down a totally wrong path at some point and it's way simpler than I'm making it.

[Deadlock989]

I've spent an unreasonable amount of time trying to figure this out. Like well over 160 hours. I bet money that I got confused and went down a totally wrong path at some point and it's way simpler than I'm making it.

No, it's very difficult and bizarre and bordering on black magic. I have also wasted a huge amount of time on this and ended up with barely adequate results, which needed a combination of about a hundred game restarts to troubleshoot the guesses I was pulling out of thin air while also trying to dredge up dusty memories of trigonometry classes I took 30 years ago.

[raspberrypuppies]

It's reassuring that you had trouble with it too. The trigonometry struggles are real. It took me a while to figure out how to translate a 3D point in the model, to a 2D orthographic sprite coordinate, and finally to a 2D Factorio coordinate.

One of the oddities is how the turret's barrel basically gets squished to produce a ellipse instead of a circle. It seems like Factorio uses the angle from target in Factorio units to calculate which turret rotation sprite to use. BUT 45 degrees in Factorio units doesn't line up with 45 degrees in sprite units so the turret might aim slightly off when fighting close enemies. I think this contributes to why the muzzle flash is always off.

[Deadlock989]

Yes, this is the main problem. When you build your 3D model, you know the z height of the barrel and the length of the barrel in the xy plane. The issue I never nailed was how calculate from those values to get the value of the source_offset in the action_delivery of the ammo_type of the attack_parameters (corresponding to the length of the barrel) and the source_offset in the root in the attack_parameters (corresponding to the height of the barrel from the ground). I gave up a lot of leisure time having to fiddle with numbers and eyeballing it. I was asking about this back in 2019 and didn't get anywhere.

A couple of years later, for one particular turret I wanted an attack effect which was entirely drawn with the rendering API, triggered by a custom script effect when the turret attacked: a lightning bolt that was rotated and stretched. I couldn't figure out for ages how to get the point of the turret muzzle based on the orientation of the turret. For that I needed the screen coordinate of the end of the barrel based on the turret's orientation so I could rotate/translate/scale the bolt's sprite. I asked for help and found out that by default, Factorio does some odd compensation for orientation which results in a non-smooth mapping of orientation to animation frame. You can see this in modded radar entities (which weirdly use a RotatedSprite with an orientation and rotation speed rather than a simple working animation like any other non-turret entity) which by default appear to weirdly speed up and slow down as they approach the cardinal directions. Turrets and vehicles are also affected by this because their components are also RotatedSprites, which is why vehicles feel like they're changing rotation speed if you drive in a circle or rotate a stationary tank vehicle. I don't know whether the calculation of the projectile/beam offset takes that into account properly or not - I want to say not, because of the way the muzzle flash / projectile or beam origin consistently misses the right place. If all else fails you could try turning this projection mapping off by setting the apply_projection property of the sprite to false, giving you a smoother rotation based on orientation, or if you don't want to turn the projection off but need to know the coordinates of the ellipse you can use the function I discovered in the link above. Another weirdness is that an orientation of 0 in Factorio is facing due north, but the trig functions in the Lua library treat 0 as east, so you are constantly having to add and subtract 0.25. But none of that helps with getting the source_offsets for real beams and projectiles at all.

[raspberrypuppies]

Thank you for those links. They're very enlightening. I had no idea that rotations were processed non-linearly. I had noticed that I could get my formulas to be accurate near the cardinal directions but never inbetween. I bet the non linear math is what threw me off.

I'll play around with those formulas and post an update. I hope they magically fix everything.

I documented my best understanding of the magic numbers in the wiki. I figured out by zero-ing out everything and setting numbers one at a time. Some variables interact with each other so that method can only do so much.

[raspberrypuppies]

This snippet from "Factorio\data\base\prototypes\entity\fire.lua" looks promising. It translates 3D model coordinates to Factorio2D ones to place the little pilot light on flamethrower turrets.

It translates a 3D point for all rotations across multiple animation frames to 2D points.

Code: Select all

  for r = 0, opts.orientation_count-1 do
    local phi = (r / opts.orientation_count - 0.25) * math.pi * 2
    local generated_frames = {}
    for i = 0, opts.frame_count-1 do
      local k = opts.run_mode == "backward" and (opts.frame_count - i - 1) or i
      local progress = opts.progress or (k / (opts.frame_count - 1))

      local matrix = math3d.matrix4x4
      local mat = matrix.compose({
        matrix.translation_vec3(math3d.vector3.mul(model.tilt_pivot, -1)),
        matrix.rotation_y(progress * delta_angle),
        matrix.translation_vec3(model.tilt_pivot),
        matrix.rotation_z(phi),
        matrix.scale(1 / model.units_per_tile, 1 / model.units_per_tile, -1 / model.units_per_tile)
      })

      local vec = math3d.matrix4x4.mul_vec3(mat, model.gun_tip_lowered)
      table.insert(generated_frames, math3d.project_vec3(vec))
    end
    local direction_data = { frames = generated_frames }
    if (opts.layers and opts.layers[r]) then
      direction_data.render_layer = opts.layers[r]
    end
    table.insert(generated_orientations, direction_data)
  end

Let's see what this "math3d.project_vec3(vec)" does...

Code: Select all

math3d.projection_constant = 0.7071067811865

function math3d.project_vec3(vec3)
  return
  {
    vec3[1],
    (vec3[2] + vec3[3]) * math3d.projection_constant
  }
end

This is unfortunately one of the formulas I've tried.

[raspberrypuppies]

That works perfectly with zero fuss for the little pilot light sprite on fluid turrets. I wonder what other ones the standard ortho formula works well for.