New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Randomized textures (sprite strip) #2746

Open
KenneyNL opened this Issue May 31, 2015 · 59 comments

Comments

Projects
None yet
@KenneyNL

KenneyNL commented May 31, 2015

In a same way that nodes are currently animated (sprite strip) it could also function to give nodes a random appearance. Upon placing the node, a random frame of the stripe strip will be selected. The random seed could be done using a noise.

This would eliminate the duplication of nodes to achieve random node textures.

@KenneyNL KenneyNL changed the title from Randomized textures to Randomized textures (sprite strip) May 31, 2015

@celeron55

This comment has been minimized.

Show comment
Hide comment
@celeron55
Member

celeron55 commented May 31, 2015

OK

@C1ffisme

This comment has been minimized.

Show comment
Hide comment
@C1ffisme

C1ffisme May 31, 2015

I made an issue like this at some point, I guess it got lost.

C1ffisme commented May 31, 2015

I made an issue like this at some point, I guess it got lost.

@TeTpaAka

This comment has been minimized.

Show comment
Hide comment
@TeTpaAka

TeTpaAka May 31, 2015

Contributor

#2433 is related. I think this was the one @C1ffisme meant.

Contributor

TeTpaAka commented May 31, 2015

#2433 is related. I think this was the one @C1ffisme meant.

@KenneyNL

This comment has been minimized.

Show comment
Hide comment
@KenneyNL

KenneyNL May 31, 2015

#2433 would still clutter the texture folder though with multiple alternatives of the same texture, I think having them all in 1 texture file is a bit more handy.

KenneyNL commented May 31, 2015

#2433 would still clutter the texture folder though with multiple alternatives of the same texture, I think having them all in 1 texture file is a bit more handy.

@C1ffisme

This comment has been minimized.

Show comment
Hide comment
@C1ffisme

C1ffisme Jun 1, 2015

I dunno, it may help some people with texture packs, depending on what they are trying to do.

We could add both as an alternative for people.

C1ffisme commented Jun 1, 2015

I dunno, it may help some people with texture packs, depending on what they are trying to do.

We could add both as an alternative for people.

@ExcaliburZero

This comment has been minimized.

Show comment
Hide comment
@ExcaliburZero

ExcaliburZero Jun 1, 2015

Contributor

This feature sounds like it could be useful.

I agree with KenneyNL that it would probably be better to use sprite strips rather than individual files, as it would be more like the current system for animated nodes.

Contributor

ExcaliburZero commented Jun 1, 2015

This feature sounds like it could be useful.

I agree with KenneyNL that it would probably be better to use sprite strips rather than individual files, as it would be more like the current system for animated nodes.

@Wuzzy2

This comment has been minimized.

Show comment
Hide comment
@Wuzzy2

Wuzzy2 Jun 2, 2015

Contributor

Some questions arise:

How and when should the sprite be selected?
And how and where will the selected sprite be stored?

Should the sprite be allowed to change on a game restart?
Should it be equally for all clients or does every client determine the sprite by itself?

Contributor

Wuzzy2 commented Jun 2, 2015

Some questions arise:

How and when should the sprite be selected?
And how and where will the selected sprite be stored?

Should the sprite be allowed to change on a game restart?
Should it be equally for all clients or does every client determine the sprite by itself?

@KenneyNL

This comment has been minimized.

Show comment
Hide comment
@KenneyNL

KenneyNL Jun 2, 2015

Some things I can answer from a game designer perspective;

  1. Upon placing/constructing the node.
  2. Using some sort of noise algorithm? No idea on that.
  3. Nope, random textures should stay the same.
  4. It should be equal for everyone.

KenneyNL commented Jun 2, 2015

Some things I can answer from a game designer perspective;

  1. Upon placing/constructing the node.
  2. Using some sort of noise algorithm? No idea on that.
  3. Nope, random textures should stay the same.
  4. It should be equal for everyone.
@4aiman

This comment has been minimized.

Show comment
Hide comment
@4aiman

4aiman Jun 4, 2015

Contributor
  1. Wasn't the increase of additional info to store amongst the reasons to decline coloured light sources? (I'm only asking)
Contributor

4aiman commented Jun 4, 2015

  1. Wasn't the increase of additional info to store amongst the reasons to decline coloured light sources? (I'm only asking)
@PilzAdam

This comment has been minimized.

Show comment
Hide comment
@PilzAdam

PilzAdam Jun 4, 2015

Member

@4aiman there is no need to store this extra information; it can be pseudo-randomly generated each time the mapblock mesh is updated.

Member

PilzAdam commented Jun 4, 2015

@4aiman there is no need to store this extra information; it can be pseudo-randomly generated each time the mapblock mesh is updated.

@C1ffisme

This comment has been minimized.

Show comment
Hide comment
@C1ffisme

C1ffisme Jun 4, 2015

@PilzAdam Now there's a good idea, give the man a medal!

Okay, so it's kindof hard to do that over the internet.

In fact, we could just use the seed provided by the world already, seeing as it's used for the rest of mapgen. That might work.

C1ffisme commented Jun 4, 2015

@PilzAdam Now there's a good idea, give the man a medal!

Okay, so it's kindof hard to do that over the internet.

In fact, we could just use the seed provided by the world already, seeing as it's used for the rest of mapgen. That might work.

@4aiman

This comment has been minimized.

Show comment
Hide comment
@4aiman

4aiman Jun 5, 2015

Contributor

@PilzAdam so the textures will "dance" on every update?
I thought the original idea was to preserve the selected texture over time.

Contributor

4aiman commented Jun 5, 2015

@PilzAdam so the textures will "dance" on every update?
I thought the original idea was to preserve the selected texture over time.

@cheapie

This comment has been minimized.

Show comment
Hide comment
@cheapie

cheapie Jun 5, 2015

Contributor

@4aiman I think the idea was to have the seed be based off of the mapblock position, so that the "random" numbers will be the same every time for any given mapblock.

Contributor

cheapie commented Jun 5, 2015

@4aiman I think the idea was to have the seed be based off of the mapblock position, so that the "random" numbers will be the same every time for any given mapblock.

@ExcaliburZero

This comment has been minimized.

Show comment
Hide comment
@ExcaliburZero

ExcaliburZero Jun 5, 2015

Contributor

I think as C1ffisme and cheapie mentioned, if the random texture would be based on either just the node position or both the node position and the map seed (for a little bit more randomness), then the texture chosen should appear to be "random" while still remaining consistent.

Contributor

ExcaliburZero commented Jun 5, 2015

I think as C1ffisme and cheapie mentioned, if the random texture would be based on either just the node position or both the node position and the map seed (for a little bit more randomness), then the texture chosen should appear to be "random" while still remaining consistent.

@4aiman

This comment has been minimized.

Show comment
Hide comment
@4aiman

4aiman Jun 5, 2015

Contributor

Oh... now I get it :)
So, I won't be able to really choose the texture (i.e. every time I place a node in a certain position it will use the same texture)?
I'd rather want to be able to control the pattern by choosing a texture somehow.

I acknowledge that the initial problem raised in current issue will be solved and fully covered by PilzAdam's solution, but still..

Also, there's a separate issue about the connected textures.
It would be nice to integrate those into this solution while also creating a way to select the chosen texture (i.e. override the pseudo-randomly chosen one).
Step-by-step.

How hard would it be to add a way to use metadata to store the number of the texture?
A certain pre-defined field name can be used.
Will that kill performance?

Contributor

4aiman commented Jun 5, 2015

Oh... now I get it :)
So, I won't be able to really choose the texture (i.e. every time I place a node in a certain position it will use the same texture)?
I'd rather want to be able to control the pattern by choosing a texture somehow.

I acknowledge that the initial problem raised in current issue will be solved and fully covered by PilzAdam's solution, but still..

Also, there's a separate issue about the connected textures.
It would be nice to integrate those into this solution while also creating a way to select the chosen texture (i.e. override the pseudo-randomly chosen one).
Step-by-step.

How hard would it be to add a way to use metadata to store the number of the texture?
A certain pre-defined field name can be used.
Will that kill performance?

@ExcaliburZero

This comment has been minimized.

Show comment
Hide comment
@ExcaliburZero

ExcaliburZero Jun 5, 2015

Contributor

@4aiman I agree that it would probably be good to have a way to set the texture of the node, as that would open up a lot of other possibilities such as connected nodes, nodes that change their appearance (like furnaces, battery boxes), etc. In the case of a random texture a random number could just be selected on create to determine the random texture.

However, I'm not sure how well that would end up working in terms of storing the metadata.

Contributor

ExcaliburZero commented Jun 5, 2015

@4aiman I agree that it would probably be good to have a way to set the texture of the node, as that would open up a lot of other possibilities such as connected nodes, nodes that change their appearance (like furnaces, battery boxes), etc. In the case of a random texture a random number could just be selected on create to determine the random texture.

However, I'm not sure how well that would end up working in terms of storing the metadata.

@4aiman

This comment has been minimized.

Show comment
Hide comment
@4aiman

4aiman Jun 5, 2015

Contributor

@ExcaliburZero I'm not insisting on anything.
I'm just trying to find a way to suppress the growth of the size of a mapblock. :)
All because of the fact that initial coloured light was declined due to doubling (or so I was told) the size of a mapblock.

Contributor

4aiman commented Jun 5, 2015

@ExcaliburZero I'm not insisting on anything.
I'm just trying to find a way to suppress the growth of the size of a mapblock. :)
All because of the fact that initial coloured light was declined due to doubling (or so I was told) the size of a mapblock.

@sofar

This comment has been minimized.

Show comment
Hide comment
@sofar

sofar Apr 10, 2016

Member

This can be implemented using a simple random number generator that is seeded for each surface with e.g. (x + z <<8 + y <<16 + face). For an example how to make randomness consistent across mesh/map updates look at my random_xz patch or the "plant fun" patch which has this element in it. (PR 3923)

Member

sofar commented Apr 10, 2016

This can be implemented using a simple random number generator that is seeded for each surface with e.g. (x + z <<8 + y <<16 + face). For an example how to make randomness consistent across mesh/map updates look at my random_xz patch or the "plant fun" patch which has this element in it. (PR 3923)

@Ryan-Nolan

This comment has been minimized.

Show comment
Hide comment
@Ryan-Nolan

Ryan-Nolan Apr 28, 2016

Would storing a single number make such a big diffrence to map block size? i have very little understanding of that at the moment. but it does seem like an extremly small amount of data..

this feature would also mean less nodes being created due to the many nodes that create 2 of each for purposes of having diffrent looks etc..

Grass textured nodes would especially benefit from this, being able to loose that repetative look. thats almost imposible to get rid off without leaving it looking plain.

If it really bugs people, maybe providing 2 versions of this would be better:

  1. that does the random picking of a sprite without actualy storing it.(in other words it would be diffrent everytime the node is loaded.)
  2. non-random that defaults to the first sprite but is changeable in the node defintion same way in the same way we fould change infotext.

so in essence you would use method 1 for things like grass and other large surfaces and you would use method 2 for things like furnaces..

getting the best of both worlds. ?

Ryan-Nolan commented Apr 28, 2016

Would storing a single number make such a big diffrence to map block size? i have very little understanding of that at the moment. but it does seem like an extremly small amount of data..

this feature would also mean less nodes being created due to the many nodes that create 2 of each for purposes of having diffrent looks etc..

Grass textured nodes would especially benefit from this, being able to loose that repetative look. thats almost imposible to get rid off without leaving it looking plain.

If it really bugs people, maybe providing 2 versions of this would be better:

  1. that does the random picking of a sprite without actualy storing it.(in other words it would be diffrent everytime the node is loaded.)
  2. non-random that defaults to the first sprite but is changeable in the node defintion same way in the same way we fould change infotext.

so in essence you would use method 1 for things like grass and other large surfaces and you would use method 2 for things like furnaces..

getting the best of both worlds. ?

@sofar

This comment has been minimized.

Show comment
Hide comment
@sofar

sofar Apr 28, 2016

Member

Having a method like random_xz had would require no map storage.

Member

sofar commented Apr 28, 2016

Having a method like random_xz had would require no map storage.

@Ryan-Nolan

This comment has been minimized.

Show comment
Hide comment
@Ryan-Nolan

Ryan-Nolan Apr 28, 2016

@sofar thats a good point. but where would it store it. In a file of its own?
And im presuming if it doesnt store it at all.. that would mean its no longer random just diffrent for each pos?

Either way it sounds like a good solution. Im just curios :)

Edit: Ive just awnsered my own question by looking at the pr: #3446 & #3923

Ryan-Nolan commented Apr 28, 2016

@sofar thats a good point. but where would it store it. In a file of its own?
And im presuming if it doesnt store it at all.. that would mean its no longer random just diffrent for each pos?

Either way it sounds like a good solution. Im just curios :)

Edit: Ive just awnsered my own question by looking at the pr: #3446 & #3923

@sofar

This comment has been minimized.

Show comment
Hide comment
@sofar

sofar Apr 28, 2016

Member

it can't be truly random, as the mesh for each block gets regenerated regularly and you don't want the texture of your grass to change just because someone placed a dirt block somewhere.

A fixed seed works well. This is all client-side as well.

Member

sofar commented Apr 28, 2016

it can't be truly random, as the mesh for each block gets regenerated regularly and you don't want the texture of your grass to change just because someone placed a dirt block somewhere.

A fixed seed works well. This is all client-side as well.

@rubenwardy

This comment has been minimized.

Show comment
Hide comment
@rubenwardy

rubenwardy Apr 28, 2016

Member

Can't you just use a RNG with a seed of (x_100+y_10+z+mapgenseed) % m

Member

rubenwardy commented Apr 28, 2016

Can't you just use a RNG with a seed of (x_100+y_10+z+mapgenseed) % m

@sofar

This comment has been minimized.

Show comment
Hide comment
@sofar

sofar Apr 28, 2016

Member

@rubenwardy that's what that is.

Member

sofar commented Apr 28, 2016

@rubenwardy that's what that is.

@paramat

This comment has been minimized.

Show comment
Hide comment
@paramat

paramat Apr 29, 2016

Member

Clever idea but i feel it is over-complex to move towards needing multiple textures per node face. I know it would be 'optional' but i don't think over-complex non-essential ideas should be encouraged or accepted in Minetest even as options.
With our dev shortage we need to keep things simple and resist overly fancy stuff. Our worlds look fine with repeating nodes and we manage fine without them. For those used to this feature in Minecraft, too bad, don't let that make you see Minetest as worse, don't compare the two, they have an army of paid devs.
This affects meshgen which is our bottleneck, so needs a lot of justification.

Member

paramat commented Apr 29, 2016

Clever idea but i feel it is over-complex to move towards needing multiple textures per node face. I know it would be 'optional' but i don't think over-complex non-essential ideas should be encouraged or accepted in Minetest even as options.
With our dev shortage we need to keep things simple and resist overly fancy stuff. Our worlds look fine with repeating nodes and we manage fine without them. For those used to this feature in Minecraft, too bad, don't let that make you see Minetest as worse, don't compare the two, they have an army of paid devs.
This affects meshgen which is our bottleneck, so needs a lot of justification.

@Ryan-Nolan

This comment has been minimized.

Show comment
Hide comment
@Ryan-Nolan

Ryan-Nolan May 1, 2016

I agree, @paramat I love the work you have done. the mapgen V7 is awsome..... but based on your anology rivers and mountains would be classed as too complex... so they shouldnt be threre?

This has nothing todo with wether minecraft uses it or not, this is based on what minetest devs/users want and overall it looks like it is wanted my the majority of those that have commented both in this issue and others like it.

This idea will improve both the overall visual looks of the game and the quality of mods that use multiple nodes to create the same effect.

Ryan-Nolan commented May 1, 2016

I agree, @paramat I love the work you have done. the mapgen V7 is awsome..... but based on your anology rivers and mountains would be classed as too complex... so they shouldnt be threre?

This has nothing todo with wether minecraft uses it or not, this is based on what minetest devs/users want and overall it looks like it is wanted my the majority of those that have commented both in this issue and others like it.

This idea will improve both the overall visual looks of the game and the quality of mods that use multiple nodes to create the same effect.

@hunter688

This comment has been minimized.

Show comment
Hide comment
@hunter688

hunter688 May 30, 2016

Screenshot from Eloraam's Minecraft clone (RedPower 3):

https://twitter.com/therealeloraam

tiling

will be awesome in the Minetest

hunter688 commented May 30, 2016

Screenshot from Eloraam's Minecraft clone (RedPower 3):

https://twitter.com/therealeloraam

tiling

will be awesome in the Minetest

@infmagic2047

This comment has been minimized.

Show comment
Hide comment
@infmagic2047

infmagic2047 May 30, 2016

Contributor

It should probably be done in a way that allows texture packs to supply more or less textures.

Contributor

infmagic2047 commented May 30, 2016

It should probably be done in a way that allows texture packs to supply more or less textures.

@paramat

This comment has been minimized.

Show comment
Hide comment
@paramat

paramat May 31, 2016

Member

I don't thnk it improves appearence by much, if at all, the screenshots above show a badly designed texture in the first example so those are misleading.
Minetest worlds look fine as they are with repeating textures, i obsessively watch Minecraft videos and have never thought their use of randomised textures improves the appearence. After all a voxel world is all about identical cubes.
I still don't think it's worth the extra complexity in our critical bottleneck of meshgen, and moves towards an expectation of multiple textures per node makes modding and texturing more difficult.

Member

paramat commented May 31, 2016

I don't thnk it improves appearence by much, if at all, the screenshots above show a badly designed texture in the first example so those are misleading.
Minetest worlds look fine as they are with repeating textures, i obsessively watch Minecraft videos and have never thought their use of randomised textures improves the appearence. After all a voxel world is all about identical cubes.
I still don't think it's worth the extra complexity in our critical bottleneck of meshgen, and moves towards an expectation of multiple textures per node makes modding and texturing more difficult.

@Fixer-007

This comment has been minimized.

Show comment
Hide comment
@Fixer-007

Fixer-007 May 31, 2016

Contributor

I guess with a nice balanced texture you don't need to randomise anything. On those screenshots above we have both bad texture and North Korea like design :)

Contributor

Fixer-007 commented May 31, 2016

I guess with a nice balanced texture you don't need to randomise anything. On those screenshots above we have both bad texture and North Korea like design :)

@0-afflatus

This comment has been minimized.

Show comment
Hide comment
@0-afflatus

0-afflatus May 31, 2016

I think it's a great idea, but it does depend on the implementation being simple and general enough. I could live without it just as easily.

0-afflatus commented May 31, 2016

I think it's a great idea, but it does depend on the implementation being simple and general enough. I could live without it just as easily.

@paramat

This comment has been minimized.

Show comment
Hide comment
@paramat

paramat Jul 4, 2016

Member

Duplicate of #2433

Member

paramat commented Jul 4, 2016

Duplicate of #2433

@sfan5 sfan5 closed this Jul 4, 2016

@paramat

This comment has been minimized.

Show comment
Hide comment
@paramat

paramat Aug 16, 2016

Member

Re-opening as this has more discussion than #2433 and discusses that method too.
Closing #2433 as the duplicate even though that came first.

Member

paramat commented Aug 16, 2016

Re-opening as this has more discussion than #2433 and discusses that method too.
Closing #2433 as the duplicate even though that came first.

@numberZero

This comment has been minimized.

Show comment
Hide comment
@numberZero

numberZero Jun 18, 2017

Contributor

This conflicts with merging nodes in stripes. But as that merging doesn’t seem to affect performance (maybe it does on older GFX, but on my GeForce 8400 GS only output size matters), that’s not a problem, it just should be optional. Moreover, node colorization conflicts with that already, and this looks like an alternative for that, although actual use cases may be different. But still, param2 seems to be the place for the frame index, as it is for color now =)

Contributor

numberZero commented Jun 18, 2017

This conflicts with merging nodes in stripes. But as that merging doesn’t seem to affect performance (maybe it does on older GFX, but on my GeForce 8400 GS only output size matters), that’s not a problem, it just should be optional. Moreover, node colorization conflicts with that already, and this looks like an alternative for that, although actual use cases may be different. But still, param2 seems to be the place for the frame index, as it is for color now =)

@paramat

This comment has been minimized.

Show comment
Hide comment
@paramat

paramat Sep 13, 2017

Member

Consider sofar's idea:

I wouldn't do a sprite strip. We already have this exact mechanism for sounds: e.g. if you request "sound_place" you can get any of "sound_place.ogg" "sound_place.1.ogg" "sound_place.2.ogg" "sound_place.3.ogg". This sounds much more generic and could be used for any texture, including normal maps and overlays.

Member

paramat commented Sep 13, 2017

Consider sofar's idea:

I wouldn't do a sprite strip. We already have this exact mechanism for sounds: e.g. if you request "sound_place" you can get any of "sound_place.ogg" "sound_place.1.ogg" "sound_place.2.ogg" "sound_place.3.ogg". This sounds much more generic and could be used for any texture, including normal maps and overlays.

@numberZero

This comment has been minimized.

Show comment
Hide comment
@numberZero

numberZero Sep 13, 2017

Contributor

So, we have several options:

  1. param2-based texture choosing. Fully controllable, suitable for various usage patterns. Requires param2 to be set in the map (thus increasing compressed size), so not very good for large solid chunks.
  2. Random texture choosing. Suitable for large areas to reduce visual repetitiveness.
  3. Large textures (#6105). Designed for large areas for the same reason.

I’d prefer (1) and (3) (for different use cases), but have nothing against (2) as yet another option. We have random Y-offset for plantlike, after all.

P.S. @paramat What sofar suggests is just an implementation detail. It looks acceptable both for (1) and (2). Just note that such texture usage is not GPU-friendly per se, so needs some tricks to work well. (Really, the whole MT needs these tricks, like using texture atlases).

Contributor

numberZero commented Sep 13, 2017

So, we have several options:

  1. param2-based texture choosing. Fully controllable, suitable for various usage patterns. Requires param2 to be set in the map (thus increasing compressed size), so not very good for large solid chunks.
  2. Random texture choosing. Suitable for large areas to reduce visual repetitiveness.
  3. Large textures (#6105). Designed for large areas for the same reason.

I’d prefer (1) and (3) (for different use cases), but have nothing against (2) as yet another option. We have random Y-offset for plantlike, after all.

P.S. @paramat What sofar suggests is just an implementation detail. It looks acceptable both for (1) and (2). Just note that such texture usage is not GPU-friendly per se, so needs some tricks to work well. (Really, the whole MT needs these tricks, like using texture atlases).

@Ryan-Nolan

This comment has been minimized.

Show comment
Hide comment
@Ryan-Nolan

Ryan-Nolan Dec 8, 2017

Whilst we are on this subject... is there a reason why we use different texture files for each face instead of 1 texture that wraps the node? i would think the latter would be more efficient

Ryan-Nolan commented Dec 8, 2017

Whilst we are on this subject... is there a reason why we use different texture files for each face instead of 1 texture that wraps the node? i would think the latter would be more efficient

@NathanSalapat

This comment has been minimized.

Show comment
Hide comment
@NathanSalapat

NathanSalapat Dec 8, 2017

Contributor

@Ryan-Nolan If we used one file with each face a texture would have to be six times larger if every face was the same, as it would have to include the same texture six times. Now it's possible that somehow it could be coded to read differently depending on the texture size, but then if you wanted to have two faces different you'd still have to use a texture with all six faces on it. Like @tobyplowy said not very efficient for artists and it would lead to bloat.

Contributor

NathanSalapat commented Dec 8, 2017

@Ryan-Nolan If we used one file with each face a texture would have to be six times larger if every face was the same, as it would have to include the same texture six times. Now it's possible that somehow it could be coded to read differently depending on the texture size, but then if you wanted to have two faces different you'd still have to use a texture with all six faces on it. Like @tobyplowy said not very efficient for artists and it would lead to bloat.

@rubenwardy

This comment has been minimized.

Show comment
Hide comment
@rubenwardy

rubenwardy Dec 8, 2017

Member

It also wouldn't help with performance at all. The Engine doesn't render all sides of a cube. A related optimisation which would be worth doing is texture atlasing - this existed in previous versions (until 0.4.2 or so) but was buggy due to a bad implementation. I believe this could have a good performance improvement by not switching texture context when rendering.

Member

rubenwardy commented Dec 8, 2017

It also wouldn't help with performance at all. The Engine doesn't render all sides of a cube. A related optimisation which would be worth doing is texture atlasing - this existed in previous versions (until 0.4.2 or so) but was buggy due to a bad implementation. I believe this could have a good performance improvement by not switching texture context when rendering.

@tacotexmex

This comment has been minimized.

Show comment
Hide comment
@tacotexmex

tacotexmex Apr 12, 2018

Contributor

sofar is on point with this comment: We already have it for sounds, why not textures too? There's plenty of texture packs with multiple alternates that can support it immediately.

Currently I have to register 5-10 node definitions for each unique node in order to support it. And that's only when placing the node (on_place), not in mapgen at all.

A quite horrible example shouldn't have to botch the whole issue. (Though #2433 is a better fit for this specific solution)

Contributor

tacotexmex commented Apr 12, 2018

sofar is on point with this comment: We already have it for sounds, why not textures too? There's plenty of texture packs with multiple alternates that can support it immediately.

Currently I have to register 5-10 node definitions for each unique node in order to support it. And that's only when placing the node (on_place), not in mapgen at all.

A quite horrible example shouldn't have to botch the whole issue. (Though #2433 is a better fit for this specific solution)

@numberZero

This comment has been minimized.

Show comment
Hide comment
@numberZero

numberZero Apr 12, 2018

Contributor

Because we are still limited to IrrLicht, which lacks texture arrays, for example. Animation is done by choosing a texture (by name!) before even starting rendering (the texture strip itself is only used to cut these parts from it). But the same hack with normal nodes will mean using several times more textures, that's not very good as texture changing is slow, and that will slow meshgen (which is our bottleneck) down considerably too. OTOH, using strip as is would mean bugs at edges.

Seriously, I may eventually fork IrrLicht and add support for some cool features I and we need... sfan5 confirms that’s a good idea)

UPD: fixed the name, that was sfan5 and not nerzhul. http://irc.minetest.net/minetest-dev/2017-12-28#i_5182234

Contributor

numberZero commented Apr 12, 2018

Because we are still limited to IrrLicht, which lacks texture arrays, for example. Animation is done by choosing a texture (by name!) before even starting rendering (the texture strip itself is only used to cut these parts from it). But the same hack with normal nodes will mean using several times more textures, that's not very good as texture changing is slow, and that will slow meshgen (which is our bottleneck) down considerably too. OTOH, using strip as is would mean bugs at edges.

Seriously, I may eventually fork IrrLicht and add support for some cool features I and we need... sfan5 confirms that’s a good idea)

UPD: fixed the name, that was sfan5 and not nerzhul. http://irc.minetest.net/minetest-dev/2017-12-28#i_5182234

@rubenwardy

This comment has been minimized.

Show comment
Hide comment
@rubenwardy

rubenwardy Apr 12, 2018

Member

Buildaworld have a fork of irrlicht with some more graphics features, may be worth looking at that

Member

rubenwardy commented Apr 12, 2018

Buildaworld have a fork of irrlicht with some more graphics features, may be worth looking at that

@numberZero

This comment has been minimized.

Show comment
Hide comment
@numberZero

numberZero Apr 12, 2018

Contributor

@rubenwardy Their fork looks great! It seems to have everything we need!

Of course it needs some adoption, e.g. they dropped Win32 support recently, we can’t do that. But it looks very-very promising)

Contributor

numberZero commented Apr 12, 2018

@rubenwardy Their fork looks great! It seems to have everything we need!

Of course it needs some adoption, e.g. they dropped Win32 support recently, we can’t do that. But it looks very-very promising)

@tacotexmex

This comment has been minimized.

Show comment
Hide comment
@tacotexmex

tacotexmex Apr 14, 2018

Contributor

Since I disliked the previous example I felt obliged to come up with a better one. Here's Pixel Perfection with 3–10 alternating textures per node. My favorite is the stonebrick wall.

screenshot_20180414_132339
screenshot_20180414_132342

Contributor

tacotexmex commented Apr 14, 2018

Since I disliked the previous example I felt obliged to come up with a better one. Here's Pixel Perfection with 3–10 alternating textures per node. My favorite is the stonebrick wall.

screenshot_20180414_132339
screenshot_20180414_132342

@4w

This comment has been minimized.

Show comment
Hide comment
@4w

4w Apr 14, 2018

I implemented that in Lua without any need for texture or engine changes. It works, but it’s hacky, though 😄

dirt
grass_sand
sand_only

See this version of the implementation

4w commented Apr 14, 2018

I implemented that in Lua without any need for texture or engine changes. It works, but it’s hacky, though 😄

dirt
grass_sand
sand_only

See this version of the implementation

@tacotexmex

This comment has been minimized.

Show comment
Hide comment
@tacotexmex

tacotexmex Apr 14, 2018

Contributor

That solution is fine if you just want random rotation of nodes, but it doesn’t work reliably for alternating textures (no other interacting mod will recognize default:stone_2 etc).

Contributor

tacotexmex commented Apr 14, 2018

That solution is fine if you just want random rotation of nodes, but it doesn’t work reliably for alternating textures (no other interacting mod will recognize default:stone_2 etc).

@4w

This comment has been minimized.

Show comment
Hide comment
@4w

4w Apr 15, 2018

That solution is fine if you just want random rotation of nodes,

The solution is horribly hacky and after releasing it a better solution without flooding the world with metadata came in my mind 😄

but it doesn’t work reliably for alternating textures […]

Yes, rotating nodeboxes would break how they are intended to look, but that wasn’t my goal. If ever properly implemented this implementation should handle it correctly and not simply override/force anything.

With my hacky code it’s possible to define the facedirs for the nodes so all facedirs where the node looks bad in can be omitted while defining the allowed rotation facedirs. I do this for grass for example.

4w commented Apr 15, 2018

That solution is fine if you just want random rotation of nodes,

The solution is horribly hacky and after releasing it a better solution without flooding the world with metadata came in my mind 😄

but it doesn’t work reliably for alternating textures […]

Yes, rotating nodeboxes would break how they are intended to look, but that wasn’t my goal. If ever properly implemented this implementation should handle it correctly and not simply override/force anything.

With my hacky code it’s possible to define the facedirs for the nodes so all facedirs where the node looks bad in can be omitted while defining the allowed rotation facedirs. I do this for grass for example.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment