Trying to implement Shadow Mapping

For people working on the C++ code.
User avatar
Lone_Wolf
Member
Posts: 2575
Joined: Sun Apr 09, 2017 05:50
GitHub: LoneWolfHT
IRC: LandarVargan
In-game: LandarVargan

Re: is Shadow mapping desired?

by Lone_Wolf » Post

After some thought I guess it isn't up to the engine to decide how its users use it.

So I'm now fine with the ability to force a setting/feature state serverside if we also get the ability to just set the default state for it. That can come before/after this PR though. It shouldn't come with it
My ContentDB -|- Working on CaptureTheFlag -|- Minetest Forums Dark Theme!! (You need it)

User avatar
philipbenr
Member
Posts: 1897
Joined: Fri Jun 14, 2013 01:56
GitHub: philipbenr
IRC: philipbenr
In-game: robinspi
Location: United States

Re: is Shadow mapping desired?

by philipbenr » Post

hex wrote:
Sat Dec 12, 2020 15:51
But here's the thing, the built-in sunlight/moonlight is always cast from the top. So your shadow won't be aligned with that, and you will effectively see two conflicting shadows, one soft and one hard. You are trying to superimpose one light model on top of another.
I will counter with this. Why should this not be added as an experimental or in-progress feature? As I see it, Minetest is in a semi-permanent beta, and if the engine can be modified such that the lighting system can be switched between "old lighting" and "new lighting", that would be great.
hex wrote:
Sat Dec 12, 2020 15:51
That's the dumbest thing I've heard in a while. How about just... let the server control it? A server side intensity control is desirable anyway, so just make 0 disable shadow casters entirely.
That situation with pitch_move only proves that leaving things like this up to the client brings nothing but trouble. I recently had invited someone to my test server, and when I told him he's supposed to use third person mode, he was like "wait, you can't enforce that?"
I think that if you have people that misconfigure their server, there would be no way for you to enable a setting that you would otherwise have no reason to be enabled. So I think your use-case is too niche to apply globally to a setting like this. INSTEAD, if you had a setting like "enforce-no-shadows" (or "enforce-3rd-person", etc.) where those were opt-in settings, you could deny connections that didn't have those settings enabled. I think saying these settings cause nothing but trouble is a gross misstatement.
hex wrote:
Sat Dec 12, 2020 15:51
We should be trying to get away from the tyranny of client settings, not enable it.
If you're going to put it that way, I think we should also not have the tyrrany of server configuration for something as simple as cosmetics. :P

User avatar
hex
Member
Posts: 82
Joined: Sun Dec 06, 2020 04:22
IRC: hecks
In-game: hex hhhehehe

Re: is Shadow mapping desired?

by hex » Post

Lone_Wolf wrote:
Sun Dec 13, 2020 01:48
So I'm now fine with the ability to force a setting/feature state serverside if we also get the ability to just set the default state for it. That can come before/after this PR though. It shouldn't come with it
It's almost as if you're looking at all the possible choices and consistently picking the worst one.
philipbenr wrote:
Sun Dec 13, 2020 04:47
I will counter with this. Why should this not be added as an experimental or in-progress feature? As I see it, Minetest is in a semi-permanent beta, and if the engine can be modified such that the lighting system can be switched between "old lighting" and "new lighting", that would be great.
You don't even have a lick of an idea what the consequences of this "new lighting" would be. It would knock your framerate down by at least a half, look wrong all the time (holes in shadows), and we have no server-sent shaders yet to even control how shading is applied.
For game developers, having to target two conflicting lighting models makes the engine a complete joke. Client controlled tonemapping is already a sample of the retardation this will cause.
philipbenr wrote:
Sun Dec 13, 2020 04:47
INSTEAD, if you had a setting like "enforce-no-shadows" (or "enforce-3rd-person", etc.) where those were opt-in settings, you could deny connections that didn't have those settings enabled
I'm clawing my eyes out right now.
philipbenr wrote:
Sun Dec 13, 2020 04:47
If you're going to put it that way, I think we should also not have the tyrrany of server configuration for something as simple as cosmetics. :P
I'll spell it out for you very bluntly. My game is going to look like garbage with shadow mapping and people are going to blame me for it. Shadow mapping on pixel art is ketchup on a steak. You have terrible taste and you don't actually care if this makes Minetest better as a whole, you just want shadows on minetest_game or similar because it's popular in Minecraft. You would happily apply shadows to sprites or even emissive FX without thinking twice, because wow, it's a feature and it's shiny. I also once wanted everything to have shadows, bloom, DOF, motion blur and other crap but then I grew out of it.

You want anyone to start making nice things in Minetest, then you need to start accomodating them and stop pulling the ground from under them every few months. Otherwise, enjoy playing minetest_game forever. :P

Let's end this with some words from c55:
The engine's purpose is largely to provide a good platform for the content that runs on it, be it subgames or individual mods, and one of the first steps in figuring out what features to add is to hear about what modders would imagine having use for.
The most interesting content is made by individual people, not a committee.
Don't mind the lesser visuals and take full advantage of them in how they make creating unimagined things easier. There are enough games in this world that focus on visuals by taking away from everything else, or by making everything else harder to do.
One of the reason I'm putting minetest_game out of its misery is this. It can't have coherence when everyone wants everything from it. Hopefully over time some of its replacements will gain this precious property.
[...]
Everything has to match everything else visually. If something looks like it came from a different world, you can't escape that. Quality doesn't matter that much, as long as it's good enough to not be a distraction.

User avatar
philipbenr
Member
Posts: 1897
Joined: Fri Jun 14, 2013 01:56
GitHub: philipbenr
IRC: philipbenr
In-game: robinspi
Location: United States

Re: is Shadow mapping desired?

by philipbenr » Post

My previous post was attempting to illustrate that there is a way to move forward (with some bandage solutions even if absolutely required) and that it appeared to me that your complaints were fairly superficial and not well founded for a long term philosophy on the engine. If you are here to argue about code and implementation as it may well turn out, I am not talking about that, and you can just as well disregard the rest of this post. I believe that is better suited for GitHub issues, PR comments, and developer roadmaps/project timelines. I am specifically discussing a long term, open source philosophy here. And this is entirely assuming there is the talent to implement things properly, which I acknowledge. I don't think we were seeing eye to eye on that level, so I wanted to get that out of the way.
Spoiler
hex wrote:
Sun Dec 13, 2020 07:14
You don't even have a lick of an idea what the consequences of this "new lighting" would be. It would knock your framerate down by at least a half, look wrong all the time (holes in shadows), and we have no server-sent shaders yet to even control how shading is applied.
For game developers, having to target two conflicting lighting models makes the engine a complete joke. Client controlled tonemapping is already a sample of the retardation this will cause.
I have never implemented a massive change in lighting system like this, so I can't speak for the massive roadblocks it may cause. But I know enough to know that this is in fact hard as you say. I do know the basics of lighting in rasterization based rendering though, so please do not just dismiss me as some stupid random, saying "I don't know anything". I did my final project in my intro to computer graphics class on on-the-fly generation and application of normal mapping for goodness sake (poorly, though my group did complete it).

But either you seem to misunderstand my intention or I have misstated it. Regardless, I believe that there should be progression of the engine (adding new features) with the progression of the level of computing accessible to people. I believe Minetest should replace from the old lighting system that it has due to a lack of features. However, I only propose this actually be merged when it is performance-wise/support-wise feasible. If this is not what people want, so be it. But considering there is someone working towards implementing a new feature in the name of development of the engine, I believe there are at least some people that want it and I will support them at least trying to do it, even if it is ultimately rejected. That is how I think open source should be approached, as it will encourage improvements in the ultimate long run.

And before you reply I know you will probably not respond positively to this philosophy. And that is perfectly fine by me. I will agree to disagree with you. I emphasize the fact this is personal and opinion, so as not to waste either of our time.
hex wrote:
Sun Dec 13, 2020 07:14
Shadow mapping on pixel art is ketchup on a steak. You have terrible taste and you don't actually care if this makes Minetest better as a whole, you just want shadows on minetest_game or similar because it's popular in Minecraft. You would happily apply shadows to sprites or even emissive FX without thinking twice, because wow, it's a feature and it's shiny. I also once wanted everything to have shadows, bloom, DOF, motion blur and other crap but then I grew out of it.
Your personal opinion on how things look is not a universal truth. Please stop acting like it is. I know plenty of people who have played games for years and enjoy those features you have "grown out of". I also know others that enjoy the melding of graphical styles (e.g. the Lego Star Wars game or Borderlands2) Please stop trying to demean me or any of them just because you don't like it.

And please do not put words in my mouth, saying "I want to see it in Minetest because it is popular in Minecraft and don't actually care about Minetest". I actually want to see it in Minetest because A) I do think it looks good (100% opinion, I will admit) but also B) I think it would a wonderful resource for other people to get an idea of how to produce lighting effects due to the open source nature of Minetest. Minetest was what got me into the CS field, and being able to elevate the project to do the same (and more) for others would be a wonderful thing in my opinion. And once again this is my personal philosophy for open source projects, and you don't have to agree with it. Neither do the developers, who ultimately create and decide what is going on in the project.
hex wrote:
Sun Dec 13, 2020 07:14
You want anyone to start making nice things in Minetest, then you need to start accomodating them and stop pulling the ground from under them every few months.

Let's end this with some words from c55:
The engine's purpose is largely to provide a good platform for the content that runs on it, be it subgames or individual mods, and one of the first steps in figuring out what features to add is to hear about what modders would imagine having use for.
The most interesting content is made by individual people, not a committee.
Don't mind the lesser visuals and take full advantage of them in how they make creating unimagined things easier. There are enough games in this world that focus on visuals by taking away from everything else, or by making everything else harder to do.
One of the reason I'm putting minetest_game out of its misery is this. It can't have coherence when everyone wants everything from it. Hopefully over time some of its replacements will gain this precious property.
[...]
Everything has to match everything else visually. If something looks like it came from a different world, you can't escape that. Quality doesn't matter that much, as long as it's good enough to not be a distraction.
I do not see how reworking lighting would be pulling the rug out from everyone provided a similar level of functionality is supported with a new lighting system. And I fully advocate for as much backwards compatibility as possible. There would likely be some smaller changes, but in the past, these changes have generally supported the same functionality, even if visuals may look slightly different. And when there comes a point where these changes can no longer maintain backwards compatibility, a new major release should be released, as was done with Minetest 0.5. And to be clear, I know that a new lighting system can not be implemented overnight. I believe it likely wouldn't be implemented in a 0.6, possibly even 0.7 release of Minetest. But I do maintain that it being worked on should not be stopped.

Now, to address the first c55 quote, this new lighting system would enable modders to create more things. People within this thread have voiced a desire to create stained glass effects using colored lighting, something not possible with the current state of the engine. There are others that would enjoy creating fire effects, disco clubs, alien worlds/subgames, numerous other possibilities, that would be better facilitated by a rework of the lighting engine. There are features that modders do want in this theoretical lighting engine I wave my hands at.

To address the second quote, Liso is an individual, motivated to produce a very impressive bandage solution on top of what is currently there. And I agree. I am most impressed by what they have done on their own.

To address the third quote, I am not advocating for taking away anything. As I said, I advocate for backwards compatibility. And as said in a previous post, I advocate for eye candy to be entirely optional. But I also advocate for progress and improvement in the engine.

To address the fourth point, I don't believe that is being used in the correct context, but regardless, I believe that provided people are able to decide what they want the game to look like, as most times that will be in line with the creators vision. If they don't align their use to what the creator actively described to them, that is the user's fault. Once again, I maintain that I value backwards compatibility, and would rather keep out game-breaking experimental features that may cause problems. But I also believe that the engine should keep progressing.
TLDR: I believe (philosophically) that in the super-long term, progress should be made in the Minetest engine, and it should be merged into the project when it is desired and feasible in all respects. And I also believe that people should not be discouraged from trying to implement these things, even if it is ultimately rejected. I also believe that you are entitled to disagree with this sentiment. It is my own, and I do not intend to force my philosophy on anyone.

I apologize to Liso for hijacking your thread. I believe I have said my piece and I am done.

User avatar
hex
Member
Posts: 82
Joined: Sun Dec 06, 2020 04:22
IRC: hecks
In-game: hex hhhehehe

Re: Trying to implement Shadow Mapping

by hex » Post

Oh, I'm not slamming OP and his work, I appreciate it from a technical perspective, but as soon as we're talking about PRing this and rolling it in, we need a serious look at where it fits into this voxel engine, and whether it's really that important.

I presented a set of API requirements that should satisfy everyone, which exist in every game engine under the sun, and honestly, that should've been the end of it. But then you and Lonewolf keep coming up with really boneheaded "solutions" to an already solved problem (begging the client to change settings? kicking clients with the wrong settings? *not* providing an API initially? wtf?), as if the idea of the game code disabling a rendering feature was really abhorrent or something. It wouldn't affect anything other than the games and servers that flip the off switch. The fact that you argue with this at all means that you either have no idea what you're talking about, or you actually want to force this opinionated change on everyone, because you think you know better and your idea of progress is cramming it down everyone's throat. If it's neither, then back down, because there was nothing to argue about in the first place.

User avatar
philipbenr
Member
Posts: 1897
Joined: Fri Jun 14, 2013 01:56
GitHub: philipbenr
IRC: philipbenr
In-game: robinspi
Location: United States

Re: Trying to implement Shadow Mapping

by philipbenr » Post

Now that all that is cleared up, why is it absolutely necessary for the setup to be as you have laid out, with server side rendering? Are you referring to the server doing all of the shadow-mapping calculations (and all the other lighting work in a plausible future) and then sending that information over the network to just be displayed by the client? Because that is the distinction as I understand it. Client side rendering would be where the server just sends the necessary world information across the network and the client receives it and does all the work. That is the definition I was taught. And as far as I can tell, most games and engines use the client side approach, not the server side approach. Especially for a project like this, clients should deal with the heavy lifting, as that makes more sense for a distributed workload if you have a large server. That's why high end games require a reasonable amount of computing power and resources to render.

If I am using a different definition than yours or if you have a reason that I am not covering, please let me know. But if not, I totally disagree that server side rendering is necessary and that client side is the better approach for a wide scale project like Minetest.

Edit: If instead you are saying that the server simply controls the features that the client renders (which is my original thought), I see no reason for that aside from your concern about "the way things look". And I propose that people should be able to control their settings as they please across the board instead of the servers dictating what settings they must use. The server denying users with certain settings could be a bandage solution if it really is necessary for certain settings to be on or off. And that was one of my "bonehead solutions".

And our "boneheaded solutions" are an attempt to describe an implementation of what we see is standard while still appeasing your concerns about "the way things should look". So if there is confusion to clear up, please do so. Otherwise, please stop demeaning people who are trying to help. And if you do not wish to "waste your time", then I would propose just waiting until the PR and air your concerns then and stop bothering with the forums, which are a board of discussion.
Last edited by philipbenr on Mon Dec 14, 2020 08:08, edited 1 time in total.

User avatar
v-rob
Developer
Posts: 969
Joined: Thu Mar 24, 2016 03:19
GitHub: v-rob
IRC: v-rob
Location: Right behind you.

Re: Trying to implement Shadow Mapping

by v-rob » Post

I believe the idea is that the server should control whether the client is allowed to render with this shadow mapping or Minetest's current shadows, not that the server does the rendering. It sounds plausible, but I personally would hate that. I don't want the server to dictate how things to be rendered because I might have a different opinion. Certainly, it would be nice if the server would suggest visual settings to make it better, but I want the final override if I think something looks better in my own personal opinion.

My opinion on the matter aside, I don't understand why there is a push for this to be a server functionality for this shadow mapping in particular. There are plenty of other settings that the server might potentially want to regulate, e.g. connected glass, 3D/2D clouds, or smoothed or unsmoothed lighting, or even non-graphical settings. This isn't Liso's shadow mapping's responsibility at all but for another PR.
Core Developer | My Best Mods: Bridger - Slats - Stained Glass

Lars
Developer
Posts: 24
Joined: Fri Oct 13, 2017 21:12
GitHub: lhofhansl

Re: Trying to implement Shadow Mapping

by Lars » Post

Hex is offering an (reasoned) opinion and does not speak for Minetest.
Personally I think these are a client side setting, but that (likewise) is my opinion.

The interesting bit here is that the current shadows are calculated at time of Map Generation on the server and stored into the map - and that can only be undone by updating the map.

If we tell the server not to calculate shadows then blocks are generated without any shaders, and any client that doesn't do shadow mapping would have no shadows.

So client and server have to coordinate here, and that's a bit of the tricky part.

Liso
Member
Posts: 33
Joined: Thu Feb 06, 2020 10:21
GitHub: 0xLiso
In-game: Liso
Location: Valencia - Spain.
Contact:

Re: Trying to implement Shadow Mapping

by Liso » Post

Hello everyone,
I'm going to be a bit disconnected until the 28th of December ( btw it´s the Spanish's April fools day) because I have an important release in real world job. So, sorry if I'm not too active.

I see a lot of text in this thread, and I want to apologize. I never wanted to start such a flame.

Well, I have more than 20 years of experience in software development, so I faced a wide variety of personalities. And when I saw the tone of some comments in this thread, I knew it will become in to a nasty discussion.

There are some people put a lot of passion in their opinions, and that's good. But, if they only look at their own belly button (as we say in Spain) and feel they have the absolute truth, and the way they argue is with threats and disqualifications then the situation becomes really unpleasant and lot of people decide to stop arguing and the aggressive line wins.

Maybe this way to discuss works for Linus when talk about pure tech. But the reality is it hurts open source projects by driving people away.
So, in my experience, the only way to handle this is to ignore the comments that does not respect others.

After that, I want to thank Lone_Wolf, jp, Philipbenr, v-rob, Lars and everyone else for the comments. I'm going to try to answer all :).



IMHO, the server should not spend time doing work that belong to the client. If the server needs to calculate the shadows, lighting or whatever for a 100 clients, it will spend a lot of resources and in the end this will impact the performance of all the clients.

But, as Lars pointed, right now the shadows are done at the Map Generation in the server and we don´t have a simple solution to "undone" that shadows. Maybe fixing "param1" values, because right now it only give us 0 or LIGHT_MAX+1 we can do something. But I didn´t spend too much time exploring this yet.


Actually, I'm working in another front. MT has a performance problem. I call it "the forest problem", and it´s a problem of occlusion (also can be mitigated with mesh optimizations and LOD).


As I was doing some testing with SM, I realized that in some situations the FPS drop down to 15-20 fps ( intel i5-4570K + RTX 2070 , 250 blocks sight ) with Shadow Mapping disabled. (8-12 fps with SM)

So I checked the clientmap rendering and I did some quick&dirt optimizations. But even with that, the performance is really bad.

If we check the vertices we draw, we can be sending 2-3 millions vertices every frame, without seeing them at all.

And you can test this inside a forest.

As the tree mesh can´t be optimized trees are "expensive", and if we are inside a forest we will try to render hundreds of trees, that we are not going to see. And not only the trees, but also the caves and other mapblocks out of sight.


And, obviously, this make Shadow Mapping infeasible right now.

Image

The good part, is that this problem is forcing me to think other ways to handle the SM to avoid as much rendering as possible :)


BTW, to minimize the bus factor, in my github you can find the development version of the Shadow Mapping. But I must warning you, it has a LOT of artifacts and it's slow as hell :)
Attachments
fpsdropout.jpg
fpsdropout.jpg (199.31 KiB) Viewed 2285 times
Liso. - My twitter -

User avatar
hex
Member
Posts: 82
Joined: Sun Dec 06, 2020 04:22
IRC: hecks
In-game: hex hhhehehe

Re: Trying to implement Shadow Mapping

by hex » Post

Where did I ever say that servers should calculate the shadows, I just said that the client should turn it off if the server requests that.

User avatar
hex
Member
Posts: 82
Joined: Sun Dec 06, 2020 04:22
IRC: hecks
In-game: hex hhhehehe

Re: Trying to implement Shadow Mapping

by hex » Post

Also regarding the "forest problem", we don't have a forest problem, we have a drawcall problem.
The clientmap doesn't render individual trees, but a mapblock's worth of leaves at a time, then the leaves in other blocks, then all the tree bark block by block, then all the tree cross-sections, then all the dirt, then dirt-side-with-grass, etc.

Crappy occlusion is one aspect of it but you can't solve it for alpha-tested geometry without some really heavy lifting. Still, most of the problem is that mapblocks are tiny and that distinct textures can not be batched together.

See this for details on what's wrong with performance:
https://github.com/minetest/minetest/issues/10647
or use an OpenGL debugger of your choice to see for yourself.

You can batch shadow casters to some degree, but you'll have to stitch the meshes together yourself. Still, there are extra problems:
- Any material that uses an alpha texture can not be trivially batched. So leaves and plants will always be a hog. Other game engines use things like imposters to make trees bearable, we have no such option. They also often apply shadows selectively, the very same thing I've been dogpiled for suggesting.
- The sun will always see more than a camera, culling won't help you much even if you somehow made it airtight. Shadows will always be ridiculously expensive compared to zero-pass baked vertex lighting.

Honestly I should've mentioned this earlier - API aside, just getting this anywhere near acceptable performance is probably more than you signed up for. But feel free to bash me for delivering the bad news.

Liso
Member
Posts: 33
Joined: Thu Feb 06, 2020 10:21
GitHub: 0xLiso
In-game: Liso
Location: Valencia - Spain.
Contact:

Re: Trying to implement Shadow Mapping

by Liso » Post

hex wrote:
Mon Dec 14, 2020 12:46
Where did I ever say that servers should calculate the shadows, I just said that the client should turn it off if the server requests that.
I never say that. I was just answering Lars.
hex wrote:
Mon Dec 14, 2020 13:35
See this for details on what's wrong with performance:
https://github.com/minetest/minetest/issues/10647
or use an OpenGL debugger of your choice to see for yourself.
Good explanation, I'll take a deeper read when I can.
hex wrote:
Mon Dec 14, 2020 13:35
Honestly I should've mentioned this earlier - API aside, just getting this anywhere near acceptable performance is probably more than you signed up for.
Probably yes, to offer SM, or other optional eye-candy features, to the majority of the ppl we should first speed up the render.
hex wrote:
Mon Dec 14, 2020 13:35
But feel free to bash me for delivering the bad news.
I never had the intention of "bash you for delivering the bad news". Is just I don´t like threats and insults. But as I say in the first reply
Liso wrote:
Mon Dec 07, 2020 17:29
I don´t know if you are making fun, or is the way you write or I misunderstood you
Liso. - My twitter -

User avatar
rubenwardy
Moderator
Posts: 6969
Joined: Tue Jun 12, 2012 18:11
GitHub: rubenwardy
IRC: rubenwardy
In-game: rubenwardy
Location: Bristol, United Kingdom
Contact:

Re: Trying to implement Shadow Mapping

by rubenwardy » Post

I'd be happy to see shadows. I'd be even more happy to see better performance come out of this. Minetest's performance and low draw range are things that need to be improved
Renewed Tab (my browser add-on) | Donate | Mods | Minetest Modding Book

Hello profile reader

Lars
Developer
Posts: 24
Joined: Fri Oct 13, 2017 21:12
GitHub: lhofhansl

Re: Trying to implement Shadow Mapping

by Lars » Post

To be sure, I'd love to see a PR for this even without solving the client vs. server shadow stuff fixed! Don't let the discussion here discourage you. Sometimes it's hard to interpret what people really mean in their messages.

As for performance, from what I see it's indeed a number of drawcalls problem, specifically with a dedicated graphics card. I see that my card is barely 10-15% busy, and that because the CPU and GPU just playing tag and shuffling data around.

Compiling with MAP_BLOCKSIZE set to 32 (instead of 16) doubles or triples my FPS, and my card it at least 50% busy. (But MAP_BLOCKSIZE is also the unit of map loading/generation so it needs to stay small).

Liso
Member
Posts: 33
Joined: Thu Feb 06, 2020 10:21
GitHub: 0xLiso
In-game: Liso
Location: Valencia - Spain.
Contact:

Re: Trying to implement Shadow Mapping

by Liso » Post

Yes, that is the major problem. I didn't read in depth yet, but Hex propose some nice solutions to this in the provided link:

hex wrote:
Mon Dec 14, 2020 13:35
See this for details on what's wrong with performance:
https://github.com/minetest/minetest/issues/10647
or use an OpenGL debugger of your choice to see for yourself.


I'm going to try to minimize the number of calls in the SM ,and we will see then :)
Liso. - My twitter -

User avatar
rubenwardy
Moderator
Posts: 6969
Joined: Tue Jun 12, 2012 18:11
GitHub: rubenwardy
IRC: rubenwardy
In-game: rubenwardy
Location: Bristol, United Kingdom
Contact:

Re: Trying to implement Shadow Mapping

by rubenwardy » Post

There's currently a discussion about rendering optimisation going on over at IRC https://irc.minetest.net/minetest-dev/2 ... #i_5762797
Renewed Tab (my browser add-on) | Donate | Mods | Minetest Modding Book

Hello profile reader

User avatar
hex
Member
Posts: 82
Joined: Sun Dec 06, 2020 04:22
IRC: hecks
In-game: hex hhhehehe

Re: Trying to implement Shadow Mapping

by hex » Post

Lars wrote:
Mon Dec 14, 2020 16:57
To be sure, I'd love to see a PR for this even without solving the client vs. server shadow stuff fixed!
Are you saying that you'd love to see a breaking feature PRed even without a fallback, and approve it in that state? I was hoping that people with a "developer" badge would have more sense in them.

User avatar
v-rob
Developer
Posts: 969
Joined: Thu Mar 24, 2016 03:19
GitHub: v-rob
IRC: v-rob
Location: Right behind you.

Re: Trying to implement Shadow Mapping

by v-rob » Post

hex wrote:
Tue Dec 15, 2020 09:02
Lars wrote:
Mon Dec 14, 2020 16:57
To be sure, I'd love to see a PR for this even without solving the client vs. server shadow stuff fixed!
Are you saying that you'd love to see a breaking feature PRed even without a fallback, and approve it in that state? I was hoping that people with a "developer" badge would have more sense in them.
Server vs. client control doesn't belong in this PR. There's all sorts of client settings which could be considered "breaking" to the server. For instance, to come up with something off the top of my head, opaque leaves are kind of breaking for the Inside the Box server because many things are hidden inside trees, and there is no way for the person with opaque leaves to find that out. Plus, opaque leaves might look ugly with some textures. But we have no server control over opaque leaves. So yes, I would approve this PR if it works well even though it is "breaking" because there are many other things that could fall under your classification of "breaking". Server control over client settings deserves its own PR.

(Liso: Don't feel responsible for the war going on here; they happen periodically.)
Core Developer | My Best Mods: Bridger - Slats - Stained Glass

u18398

Re: Trying to implement Shadow Mapping

by u18398 » Post

To end this war I would suggest to open a new thread here. The question is not about shadows or not.
The question is: should a server owner be able to control parts of the preferences of the clients which want to connect.
Like this the discussion would be more precise.

User avatar
v-rob
Developer
Posts: 969
Joined: Thu Mar 24, 2016 03:19
GitHub: v-rob
IRC: v-rob
Location: Right behind you.

Re: Trying to implement Shadow Mapping

by v-rob » Post

Gundul wrote:
Tue Dec 15, 2020 18:12
To end this war I would suggest to open a new thread.
Good idea; this is getting offtopic.
Core Developer | My Best Mods: Bridger - Slats - Stained Glass

Lars
Developer
Posts: 24
Joined: Fri Oct 13, 2017 21:12
GitHub: lhofhansl

Re: Trying to implement Shadow Mapping

by Lars » Post

v-rob wrote:
Tue Dec 15, 2020 23:37
Gundul wrote:
Tue Dec 15, 2020 18:12
To end this war I would suggest to open a new thread.
Good idea; this is getting offtopic.
Agreed. Thanks.

I would like to state the fact that all MT developers on this thread, namely rubenwardy, v-rob, and myself were (1) tactful in tone and (2) in favour of this feature (without necessarily solving the client/server issues.) And in the end we are the ones deciding what gets merged and what does not.

Personally I think it's a shame that a single person has managed to make this look like a "war".

User avatar
Andrey01
Member
Posts: 2574
Joined: Wed Oct 19, 2016 15:18
GitHub: Andrey2470T
In-game: Andrey01
Location: Russia, Moscow

Re: Trying to implement Shadow Mapping

by Andrey01 » Post

Liso, are you going to open a PR on the github?

Liso
Member
Posts: 33
Joined: Thu Feb 06, 2020 10:21
GitHub: 0xLiso
In-game: Liso
Location: Valencia - Spain.
Contact:

Re: Trying to implement Shadow Mapping

by Liso » Post

Yes, sure. I'll do as soon as I can. It's just right now I'm too busy at work, and I want to make some changes.

But maybe I must send the PR in a WIP state just in case someone wants to help.
Liso. - My twitter -

User avatar
Andrey01
Member
Posts: 2574
Joined: Wed Oct 19, 2016 15:18
GitHub: Andrey2470T
In-game: Andrey01
Location: Russia, Moscow

Re: Trying to implement Shadow Mapping

by Andrey01 » Post

Liso wrote:
Sun Jan 03, 2021 12:06
But maybe I must send the PR in a WIP state just in case someone wants to help.
That`s what I meant is to send a PR as a draft so other people could test/suggest changes and possibly the progress would go faster.

User avatar
Andrey01
Member
Posts: 2574
Joined: Wed Oct 19, 2016 15:18
GitHub: Andrey2470T
In-game: Andrey01
Location: Russia, Moscow

Re: Trying to implement Shadow Mapping

by Andrey01 » Post

I tested out the shadows today and after that I understood why this is currently even "pre-alpha" version. There is my list of discovered bugs/lacks:
  1. First lack (very serious to me) that immediately gets revealed after joining a world is very great dropping FPS. It decreases and ranges around from 4-9, even when you are not nearby a forest, just on a plain grassland.
  2. The edges of the shadows continuously quiver at a place. At fact they should be stark and only shift dependently from the sun position?
  3. Also (at certain distance from them) the edges of the shadows look like much sharped.
  4. If nodes are uncovered, i.e. are located directly under the sun, there will appear a ripple on them like on water (and again, this effect appears from a certain distance):
    Image
  5. The shadows disappear on the nodes at distance around 100 metres.
  6. At night nodes get too dark and lush tint. They look like much brighter and fainter without the shadows:
    Image
    Also, on the screenshoot above you can notice the sharpen bright corners from both sides of the screen.
Currently that`s all what I noticed, but I think potentially here can be more different bugs in specific cases.
Attachments
Screenshot_20210107_003250.jpg
Screenshot_20210107_003250.jpg (1008.29 KiB) Viewed 2285 times
Screenshot_20210107_002508.png
Screenshot_20210107_002508.png (280.71 KiB) Viewed 2285 times

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests