It would be much better to remove the origin of the problem, that would be:
a.) Living creatures and moveable vehicles shouldn't get stuck at small amounts of material.
or....
b.) Small amounts of materials should fall down to the ground (like Fly-sand).
Would a mean vertex-areas?
Apart from that, it shouldn't be that hard to implement. There's already the special pixel counting code in the engine that disregards small pixel groups (used for oil). Destabilizing such pixel groups won't be that hard.
On the other hand, I still think that the best solution against small pixels is just removing small pixels from the game in favor of, well, bigger pixels. Though we will need some graphics code to make them look well. See also below.
In reality, most "stuck" situations arise because the movement procedures of the Clonk have some kind of loop for the given terrain, or the wrong vertex is embedded for the given procedure. Detecting both is not directly trivial. Doable, yes - but one needs to keep in mind that there are a huge number of terrains a Clonk might encounter, and dozens of different procedures that might work on it. That it works as well as does is most likely the result of an evolution of the movement procedures that stretches back a good deal to matthes' original code. And literally nobody has dared to touch the code since then because it's most likely to break more things than in fixes. Even Sven's fix for the multiple vertex attach bug turned out to have unforeseen consequences, as suddenly watchtowers could be climbed.
Now we obviously have some more flexibility with OpenClonk (I think Sven's fix is now the default). One key aspect, imo, is that we can now choose the Clonk scale freely (relative to landscape pixels). So if we just scale the Clonk down, we might cut down the number of corner cases substantially and make dealing with such situations much easier. So then it might be worth to revisit the issue. But before that, I'm not optimistic that significant improvement is possible without months of tracking down corner cases and producing horrible spaghetti code.
(And just for the record: I consider polygon landscapes to make matters worse, because it's actually even more difficult to get a grip on all possible cases.)
And what exactly do you mean by "Players are going to notice it"? Obviously you're going to see it if you're playing side by side. The real question is what kind of problems it could cause. And I, for one, can't see any substantial gameplay issues arising at least until the Clonk is about 3 pixels tall (not that I'm advocating that, I'm actually talking about 50%, tops). You can still dig, mine and have all the fun in the world. The engine will "just" have to work harder making the whole thing pretty. The engine will have to do it anyway - and I'm pretty sure anything we can come up with is going to be prettier than the ugly pixel noise left over by, say, granite.
Hm, thinking about it again, the real change a smaller Clonk would have is that there would be more vertices per area. We should probably first try to get the same effect with more vertices. The "weird behaviour with more than one vertice with the same CNAT" problem should be fixed, and the performance disadvantage might not be noticable anymore.
> Hm, thinking about it again, the real change a smaller Clonk would have is that there would be more vertices per area.
My initial idea was to cut the Clonk down to 4 vertexes or something to that effect (maybe 5 - with 2 at the top to make scaling over stuff harder?). More vertexes actually sound like more reasons for the Clonk to get stuck. I stay by my point: If we're trying new stuff, let's make sure we move into the direction of less complexity.
And a Clonk completely covered by vertices would be unable to get a stray pixel into it's body. Admittedly, it would work even better if most of those vertices would be "soft" and just gently nudge the Clonk away from the wall, instead of forcing a complete and immediate halt.
> And a Clonk completely covered by vertices would be unable to get a stray pixel into it's body.
Having no material "inside" doesn't automatically imply that you can't get stuck either. Well, admittedly, it also cuts down on the possible cases - but then again we will still have landscape changes (loam, elevator, freezing water...), teleporting and the likes. We can't just have the Clonk teleport or die when this happens. We need stuck Clonks somewhere in the design.
> are you worried that the Clonk might "stutter" when climbing?
It'll stutter just walking around. You couldn't have slightly uneven terrain anymore, you'd be limited to really uneven terrain. And the player will notice that an uneven but mostly flat terrain just has two or three different height levels.
> We can't just have the Clonk teleport or die when this happens.
Can't we? There's no reason teleport couldn't be limited to air and liquids, and the other changes are fairly local, so moving a Clonk out of the way wouldn't be teleporting.
> Can't we? There's no reason teleport couldn't be limited to air and liquids, and the other changes are fairly local, so moving a Clonk out of the way wouldn't be teleporting.
Other changes? It's just that I strongly suspect it'd be easy to have one Clonk push the other through, say, a castle wall just by using one or two loam appropriately.
Well, the problem is obviously that I can't claim to have a killer argument why we should introduce it. I do think it would save us a lot of trouble in the long run. I guess that's not enough to turn the running ship around now?
> Sure, it makes you "feel" pixels a lot more, but that's not necessarily a bad thing in my opinion, as it also makes it easier to predict what the Clonk will be doing.
Only if you can actually see the pixels as well. I haven't tried it, but imho making the player aware of the pixel based nature of the landscape is not on the list of things the player should be reminded of.
We could, for example, interpolate sub-pixel Clonk movement by just looking a step farther for the current attached vertex. That would fix the whole stuttering problem. Hq3x or friends are more than capable of making the landscape look equally smooth.
I do think we could pull this off if we want to - and I'm pretty sure we will need it anyway for the zoom to look good in all circumstances.
>Hq3x or friends
I didnt follow your discussion but regarding the landscape I need to add that I created all the textures which are now in Materials.c4g in the assumption that they will be displayed at full resolution when zoomed in 3x times. So the size of the features and details in the textures are tailored for being displayed fullres at 3x and zoomed to 33% when viewed at the standard CR zoom factor.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill