Factorio Forums

Azzinoth wrote: Mon Jun 03, 2019 6:07 pm I think randomizing the resource icons is a great idea, but to be honest it still looks very repetitive to me.

The reason is that one ore item is always represented by 4 ore chunks of almost equal size and then placed at the corners of a square. In the last picture it is most visible for copper and stone. I'm pretty sure if i would make a spatial fourier transform of these belts I would get very localized spikes. What you need to do is randomize the spatial frequency a bit more.

To do that i would make the first icon out of 4 medium sized ore chunks, the next icon out of one very big chunk, the next icon out of one bigger chunk and one smaller chunk etc. That would give you more variation of sizes and distances between visible chunks, even tough the icons all have the same distance from each other.

I personally would also sprinkle some dirt over the chunks and the space between them. They are just coming out of the ground and look too clean for my taste...

mrvn wrote: Tue Jun 04, 2019 12:03 pm While the random look on the belt looks nice for sure I wonder about the cost. Doesn't it mean you need N times as many icons for each resource. Meaning N times the graphics ram and more complex rendering setup?

Will there be an option to turn this off to reduce memory overhead without going all the way to low pixel icons?

Qon wrote: Tue Jun 04, 2019 12:56 pm

mrvn wrote: Tue Jun 04, 2019 12:03 pm While the random look on the belt looks nice for sure I wonder about the cost. Doesn't it mean you need N times as many icons for each resource. Meaning N times the graphics ram and more complex rendering setup?

Will there be an option to turn this off to reduce memory overhead without going all the way to low pixel icons?

It's only for raw resources and it's only for graphics that are already very small. The rocket silo was made 9x9 instead of 9x10 so that should free up a large porton of those extra kiB that you lost.

Really though it's a bit weird to ask for the ability to reduce video memory usage by a minuscule and unnoticeable amount while sticking with high res graphics that require many orders of magnitude more VRAM. A modern card can store millions of tiny icons.

eradicator wrote: Tue Jun 04, 2019 2:39 pm The mod should look like this :

Code: Select all

for _=1,99 do
  table.insert(icon_variations,{icon='copper-plate.png'})
  end
table.insert(icon_variations,{icon='iron-plate.png'})

Damn...now i want proper probability support. I'll call the mod Cthulhu Belts.

Qon wrote: Tue Jun 04, 2019 3:03 pm Your idea might be even eviler but might get found out earlier since it is not as subtle. So it maybe won't last long enough to drive anyone insane.

Qon wrote: Tue Jun 04, 2019 4:51 pm Well, the percentage is adjustable. If Factorio doesn't dedupe same file loaded 100000 times then you might need a mod that removes variations to deal with your VRAM problem though...

• Alpha blending between the two different layering orders in corners might work - if you can afford the overhead, as that requires composition in a dedicated layer, with opacity flushed to boolean before composing back onto the belt layer.
• Adding depth channel to sprites won't work, you would still be suffering from features clipping as the density of items varies.
• Making Z order on belt depend on movement direction rather than following NS/WE rules, probably won't work, with pre-baked lightning.

Ext3h wrote: Fri Jun 07, 2019 5:49 pm Is there any specific plan to address the unstable Z order issues, which became even more prominent after increasing the belt density? As nice as it looks on a straight piece, in corners, or on tiles adjacent to corners, you quickly notice the order shifting.

With now randomized variations, you are hitting uncanny valley.

Before you would get used to it, immersion breaks shortly around that defect, but it's an "uninteresting pattern" and as long as the belt it full, you get to "ignore" that defect eventually as it was just a repeating pattern. Now you have "unique features" moving, which are a lot harder to ignore, especially since you are triggered to track features unconsciously, so a discontinuity in an items visibility becomes immediately apparent.

That said, you need a better solution for Z order changes, if you are to introduce unique features in a packed belt. Otherwise complaints about motion sickness due to that addition are ensued.

• Alpha blending between the two different layering orders in corners might work - if you can afford the overhead, as that requires composition in a dedicated layer, with opacity flushed to boolean before composing back onto the belt layer.
• Adding depth channel to sprites won't work, you would still be suffering from features clipping as the density of items varies.
• Making Z order on belt depend on movement direction rather than following NS/WE rules, probably won't work, with pre-baked lightning.

SkiCarver wrote: Fri Jun 07, 2019 6:26 pm

Ext3h wrote: Fri Jun 07, 2019 5:49 pm Is there any specific plan to address the unstable Z order issues, which became even more prominent after increasing the belt density? As nice as it looks on a straight piece, in corners, or on tiles adjacent to corners, you quickly notice the order shifting.

With now randomized variations, you are hitting uncanny valley.

Before you would get used to it, immersion breaks shortly around that defect, but it's an "uninteresting pattern" and as long as the belt it full, you get to "ignore" that defect eventually as it was just a repeating pattern. Now you have "unique features" moving, which are a lot harder to ignore, especially since you are triggered to track features unconsciously, so a discontinuity in an items visibility becomes immediately apparent.

That said, you need a better solution for Z order changes, if you are to introduce unique features in a packed belt. Otherwise complaints about motion sickness due to that addition are ensued.

• Alpha blending between the two different layering orders in corners might work - if you can afford the overhead, as that requires composition in a dedicated layer, with opacity flushed to boolean before composing back onto the belt layer.
• Adding depth channel to sprites won't work, you would still be suffering from features clipping as the density of items varies.
• Making Z order on belt depend on movement direction rather than following NS/WE rules, probably won't work, with pre-baked lightning.

rather than trying to fix a material compression issue with z-depth, perhaps change the belt corner design. Rather than the 'luggage return' style belt with the associated shorter path on the inside, do as real ore belts do ... drop from one belt to another. (the 0.17 update includes a hint of this with the new t-junction graphic.

mrvn wrote: Sat Jun 08, 2019 8:42 am

SkiCarver wrote: Fri Jun 07, 2019 6:26 pm

Ext3h wrote: Fri Jun 07, 2019 5:49 pm ....

rather than trying to fix a material compression issue with z-depth, perhaps change the belt corner design. Rather than the 'luggage return' style belt with the associated shorter path on the inside, do as real ore belts do ... drop from one belt to another. (the 0.17 update includes a hint of this with the new t-junction graphic.

You mean like a T junction except one side of the belt is longer so it drops on the far side of the other belt?

Lubricus wrote: Sun Jun 09, 2019 9:24 am I think the ore icons on the belts is somehow off. It's to much on the belt it's looks like it will fall off the belts.
Shrinking the icons a tad could help also have a little more space between the individual rocks in the icon. Then it would be easier to se what belt it is under the gravel and probably also looking better.