draw_on_ground isn't on the ground

[Deadlock989]

You can't set render layer for rendered polygons, rectangles etc. with the rendering API, only for sprites and animations.

There is a draw_on_ground property for shapes, however, it doesn't seem to be using a render layer that's "on the ground". For example, rendered rectangles drawn "on the ground" are drawn above belts. That in itself isn't too bad. What does stick out is that the render layer for draw_on_ground is rendered above the base of inserters and turrets, but below the moving top half of inserters and turrets. It gives the impression of a floating plane that's "cutting the heads off" inserters and turrets halfway up (see image). You do not get this effect with native turret visualisations etc. because they are using a lower render layer than belts and inserter/turret bases do.

Some alternative suggestions towards a request:

- Move the draw_on_ground layer down to the same layer as native radius visualisations (radius-visualization or lower-radius-visualization). Might break existing mods.

or

- Allow us to specify the render layer for generated shapes, the same as you can for sprites and animations.

[Bilka]

It is now rendered below everything, including decoratives. This makes it equal to radius visualisation. If any modder has a problem with this, please give your opinion here.

[eradicator]

If any modder has a problem with this, please give your opinion here.

Hi there. I think i might have a problem with this. While i agree that "cutting" entities apart is ugly drawing below decoratives only works for semi-transparent solid colored green-bluish things. As soon as you start using less transparency or other colors the decoratives become "cut" off the ground like the entities above. Non-filled shapes will likely look pretty ugly in heavily grassy areas.

Is there any technical reason why draw_$shape doesn't support render_layer?

Examples:
With native (above) turrent and substation overlays you barely notice the "cut", for other colors (below) it's more obvious.

[posila]

Is there any technical reason why draw_$shape doesn't support render_layer?

Yes

[eradicator]

Is there any technical reason why draw_$shape doesn't support render_layer?

Yes

Rephrase: What is the technical reason?

[Deadlock989]

I don't think there is a perfect solution to this - as with other render layer issues.

This is purely cosmetic and far, far from being even a medium-sized deal - but I would prefer if the draw_on_ground setting was consistent with the turret radius visualisations, whatever that looks like with purple shrubs installed.

[eradicator]

I don't think there is a perfect solution to this - as with other render layer issues.

Yea, but...

I would prefer if the draw_on_ground setting was consistent with the turret radius visualisations

I would prefer if draw_$shape wasn't reduced to a single usecase. For radius visualizations it would be sufficient to use a render layer that is above decoratives but still below entities because as i said above, the difference isn't even visible! Much in contrast to the very visible difference for other usecases.

For example i have a mod that displays player health and shield below the player (like some action RPGS do). In 0.17 it worked perfectly, but with this change i can basically scrap it.

hpbubble.png (202.53 KiB) Viewed 2550 times

@Rseding has said multiple times that he would be willing to support proper radius visualization for entities that don't have them yet (i.e. here). So this change is very very unexpected to me.

[Bilka]

I would prefer if draw_$shape wasn't reduced to a single usecase. For radius visualizations it would be sufficient to use a render layer that is above decoratives but still below entities because as i said above, the difference isn't even visible!

Between which render layers would this be? List of render layers is here https://wiki.factorio.com/Types/RenderLayer , it used to draw between lower-object and transport-belt-circuit-connector, now it draws before everything (before water-tile).

@Rseding has said multiple times that he would be willing to support proper radius visualization for entities that don't have them yet (i.e. here). So this change is very very unexpected to me.

Speaking of that, you quoted the implementation of that viewtopic.php?p=474607#p474607, so I am not sure why you say it is not supported. @Deadlock, could you use this instead? I assume you need script rendering because the area is by chunk borders, so it is a different radius depending on entity placement within the chunk.

[Deadlock989]

Well, ideally I would like something to change, because turret/inserter layers are a bit wonky. Another solution is to move the render layer of turret and inserter bases. Either up or down.

e.g. Turret bases are also drawn below the shadow layer. The attached pic shows that the shadow from the both top and bottom halves of turrets is drawn over the turret bases to the right (the red turrets), but not over the top half of the turrets. For non-turrets (the non-red entities) the shadow is never drawn on top of their main animation sprite.

@Rseding has said multiple times that he would be willing to support proper radius visualization for entities that don't have them yet (i.e. here). So this change is very very unexpected to me.

I don't want a "proper radius visualisation". I want something that looks identical to the way a radius visualisation is visualised but isn't necessarily centred on an entity. Exactly the kind of thing rendered shapes are for, basically.

I guess I could just use a chunk-sized sprite, and use the draw_sprite function that does have control over render layer.

[Deadlock989]

Speaking of that, you quoted the implementation of that viewtopic.php?p=474607#p474607, so I am not sure why you say it is not supported. @Deadlock, could you use this instead? I assume you need script rendering because the area is by chunk borders, so it is a different radius depending on entity placement within the chunk.

I don't know ... Maybe? I am highlighting the chunk an entity is in. The entity's function is related to pollution so I wanted to show the affected chunk.

I mean, it's not a big deal, it works where it is, it's a very minor visual glitch. If there's going to be a song and dance about it then just put it back as it was.

[Bilka]

Reverted for now, looking into better solutions.

[eradicator]

Speaking of that, you quoted the implementation of that viewtopic.php?p=474607#p474607, so I am not sure why you say it is not supported.

Because a) i forgot about that and b) it sounded like it would be a better solution. New facts reveal that @Deadlock needs chunk aligned visualizations and i guess those aren't supported natively? (yet?) (can't find documentation for it so i don't know what it can or can not do)

I would prefer if draw_$shape wasn't reduced to a single usecase. For radius visualizations it would be sufficient to use a render layer that is above decoratives but still below entities because as i said above, the difference isn't even visible!

Between which render layers would this be? List of render layers is here https://wiki.factorio.com/Types/RenderLayer , it used to draw between lower-object and transport-belt-circuit-connector, now it draws before everything (before water-tile).

Honestly i don't know enough about which entity renders where to give a good answer to that. Neither do i understand how the visualization would even be visible if it's drawn *before* tiles? Just trying to look at what's there now i noticed that apparently radius visualization isn't even consistently in the same layer:

radiusvisbroken.png (298.67 KiB) Viewed 2509 times

Reverted for now, looking into better solutions.

Thank you for looking into it. Not knowing the technical reasons for not being able to support every layer (performance i guess?) maybe it would be feasible to support a third layer? (slippery slope *cough*)
1) default-> Above everything (unchanged)
2) Like draw_on_ground in 0.17, draws kinda in the middle of the z-stack.
3) Below everything like radius visualizations.

[Deadlock989]

I guess I could just use a chunk-sized sprite, and use the draw_sprite function that does have control over render layer.

This appears to work as I wanted it to, without beheading anything. You define a new sprite using the mining drill's radius visualisation sprite as the source, then centre it on the chunk, scale it by 102.4 in both directions (the source is 10x10 pixels), and give it an alpha.

Code: Select all

local r = rendering.draw_sprite{sprite="fake-radius", target={x = clt.x+16, y = clt.y+16}, x_scale=102.4, y_scale=102.4, tint = {r=0.2,g=0.2,b=0.2,a=0.2}, render_layer="radius-visualization", surface=player.surface, time_to_live=3600, players={event.player_index}, only_in_alt_mode=true}

[posila]

Rephrase: What is the technical reason?

So, almost entire game view is normally drawn using sprites as textured quads. There are two exceptions I can think of at the moment, so there might one or two more. The exceptions are turret and capsule range radiuses and flying text (technically, text is also just textured quads, but text rendering has much different logic from normal sprite rendering, that it ends up being an exception). Rectangular are visualizations are drawn as stretched tinted sprites (as Deadlock ended up doing).
+ there are debug visualizations that need to be just fast enought to be usable for us to debug the game. I don't consider those to be part of the game play experience.

So, the rendering backend is optimized mainly for drawing large batches of sprites. It's alright for drawing large batches of primitives, but when you start mixing sprites and primitives, you start hitting some performance penalties. Had this been problem for us, we could have design the rendering backend in a different way, to make this use case faster, but that's not how we draw things, and we optimized things for our use case.

Anyhow, I don't really mind if mods don't do things in the most optimal way, however, the drawing system is lacking infrastructure to draw primitives in between arbitrary sprite layers. There are essentially 3 layers for primitives - radiuses, under-sprites (added from pull-request by Bodals for purpose of script rendering - this is what draw_on_ground uses) and other (which is on top of everything).

tl;dr: it's not something the game needed to do, so nobody programmed in the ability for it to do it.

[posila]

I guess I could just use a chunk-sized sprite, and use the draw_sprite function that does have control over render layer.

This appears to work as I wanted it to, without beheading anything. You define a new sprite using the mining drill's radius visualisation sprite as the source, then centre it on the chunk, scale it by 102.4 in both directions (the source is 10x10 pixels), and give it an alpha.

Code: Select all

local r = rendering.draw_sprite{sprite="fake-radius", target={x = clt.x+16, y = clt.y+16}, x_scale=102.4, y_scale=102.4, tint = {r=0.2,g=0.2,b=0.2,a=0.2}, render_layer="radius-visualization", surface=player.surface, time_to_live=3600, players={event.player_index}, only_in_alt_mode=true}

Yes, if you need only square radius, this is the way to do it. Minor suggestion - good candidate for sprite to use is utility/white_square

[Deadlock989]

Yes, if you need only square radius, this is the way to do it. Minor suggestion - good candidate for sprite to use is utility/white_square

Thanks - works well, doesn't need a new sprite defined, and can be tinted any colour.

[eradicator]

[...]

Thank you for taking the time to write a detailed explanation! It's always nice to get some more insight into the internal structures.

There are essentially 3 layers for primitives

So if i understand you correctly the only problem in this thread is that the api uses a two-state value "draw_on_ground" to select from three possible options. Thus simply extending the api would make everyone happy?