[Coders needed] Colored light sources

prestidigitator
Member
 
Posts: 632
Joined: Thu Feb 21, 2013 23:54

by prestidigitator » Wed Apr 24, 2013 02:29

This is really great stuff. I think it would be amazing to have it in the engine. Don't know what to say about approaching the devs though. Wishing you better luck than I had, I guess. Stroke hmmm the right way and maybe you'll have a chance. If he's already taken a dislike, on the other hand....
 

prestidigitator
Member
 
Posts: 632
Joined: Thu Feb 21, 2013 23:54

by prestidigitator » Wed Apr 24, 2013 02:56

PilzAdam wrote:
mauvebic wrote:And i dont wanna waste time putting together a pull just to get the prestidigitator treatment.

The problem with prestidigitator was that he had coded everything on his own without talking to us.
If he had talked to hmmmm earlier, then he problably wouldnt have wasted so much work.

Actually that's the funny bit. I did bring it up early. Hmmm shot down some ideas the instant I asked about them in IRC (so I left them out of what I was doing), and then celeron55 and I had a conversation which he seems to have forgotten about in which he told me that if I implemented noise in the way I described I shouldn't worry and he wouldn't let hmmm get in the way of my contributing. Impressed by celeron55's encouragement when I was otherwise ready to let it go, I continued. Occasionally I even tried to bring up what I was doing in a context where I might get some actual constructive criticism, but the feedback tended to be along the lines of, "Cool. It'd be nice if you did THIS too. Now how about them abandoned mods/software licenses/whatever!"

Interesting story, eh?
Last edited by prestidigitator on Wed Apr 24, 2013 02:59, edited 1 time in total.
 

User avatar
MirceaKitsune
Member
 
Posts: 809
Joined: Sat May 21, 2011 22:31
GitHub: MirceaKitsune
IRC: Taoki
In-game: MirceaKitsune

by MirceaKitsune » Wed Apr 24, 2013 10:07

prestidigitator wrote:Actually that's the funny bit. I did bring it up early. Hmmm shot down some ideas the instant I asked about them in IRC (so I left them out of what I was doing), and then celeron55 and I had a conversation which he seems to have forgotten about in which he told me that if I implemented noise in the way I described I shouldn't worry and he wouldn't let hmmm get in the way of my contributing. Impressed by celeron55's encouragement when I was otherwise ready to let it go, I continued. Occasionally I even tried to bring up what I was doing in a context where I might get some actual constructive criticism, but the feedback tended to be along the lines of, "Cool. It'd be nice if you did THIS too. Now how about them abandoned mods/software licenses/whatever!"

Interesting story, eh?


It's getting harder for me to understand some of the core developers as well, and I'm slowly starting to lose that feeling of positivity from the administration for many reasons. I am grateful for c55 and the others making this project possible, but also saddened that the main developers choose to be in certain ways at certain times. That's mostly unrelated to the color lighting subject, but a general thing.

I maintain my opinion that adding two extra bits to param1 wouldn't harm anything. hmmm maintains his that the feature would be done in the bad way, and because of that 90% of the community as well as some devs wanting it should be discarded if another way can't be found. I do however agree that this would be best to do with the implementation of hardware lighting... but who's going to help do THAT one properly?
 

hmmmm
Member
 
Posts: 47
Joined: Tue Apr 02, 2013 04:04

by hmmmm » Thu Apr 25, 2013 01:21

prestidigitator wrote:Actually that's the funny bit. I did bring it up early. Hmmm shot down some ideas the instant I asked about them in IRC (so I left them out of what I was doing), and then celeron55 and I had a conversation which he seems to have forgotten about in which he told me that if I implemented noise in the way I described I shouldn't worry and he wouldn't let hmmm get in the way of my contributing. Impressed by celeron55's encouragement when I was otherwise ready to let it go, I continued. Occasionally I even tried to bring up what I was doing in a context where I might get some actual constructive criticism, but the feedback tended to be along the lines of, "Cool. It'd be nice if you did THIS too. Now how about them abandoned mods/software licenses/whatever!"

Interesting story, eh?

I don't mean to be offensive here, but your contribution wasn't that great anyway.
All you really did was shit up the entire existing noise.cpp with your own style of code and conventions that had necessarily broken every use of perlin noise already existing in the codebase.
Simplex noise and improved perlin noise, if we wanted, could've been had by grabbing the first free implementation off of google and modifiying a bit. Modulated perlin noise, I had implemented as part of Mapgen V7 in a much simpler and effective manner than what you had done.
I suppose celeron saw this and decided that the rest of what you've screwed up wasn't worth the minor additions either.

MirceaKitsune wrote:It's getting harder for me to understand some of the core developers as well, and I'm slowly starting to lose that feeling of positivity from the administration for many reasons. I am grateful for c55 and the others making this project possible, but also saddened that the main developers choose to be in certain ways at certain times. That's mostly unrelated to the color lighting subject, but a general thing.

I maintain my opinion that adding two extra bits to param1 wouldn't harm anything. hmmm maintains his that the feature would be done in the bad way, and because of that 90% of the community as well as some devs wanting it should be discarded if another way can't be found. I do however agree that this would be best to do with the implementation of hardware lighting... but who's going to help do THAT one properly?


It's not 2 extra bits. It's 32 extra bits. The extra color channels are 4 bits each, and then double that for the night lightbank. But then, you can't have a 6 byte MapNode structure, and it'll be padded to 8 bytes.
So you're sort of off there, by more than an order of magnitude.

Yes, it would harm things. Everything related to bulk MapNode data in-memory become twice as large, everything that deals with bulk MapNode takes twice as long, which is even worse since you're greatly increasing the chances of cache misses. And all code related to lighting (there's a lot) would need to be modified, so if this does get implemented the right way later on, we're left with the crapped up version of the software lighting system.
I am not denying this because of some "self-imposed restriction", but rather because there are technical problems with the code that would be necessary to do this particular, bad approach, that we are not willing to swallow. You know this.
I'm glad that 90% of the community wants this feature, but I'm simply not willing to have Minetest shitted up to this extent to get it. Remember, this was proposed once before and rejected by celeron55 himself. Why don't you have the same negative sentiment against him too?

As for hardware lighting, it seems that mauvebic is sufficiently pleased with BlockScape, which does have the same "sunlight shining through caves" problem as discussed. Blockscape does nothing about it but hope that the top loads quickly enough for the player not to notice, and some guessing of whether or not the player is underground.

Your move.
Last edited by hmmmm on Thu Apr 25, 2013 01:33, edited 1 time in total.
 

User avatar
mauvebic
Member
 
Posts: 1550
Joined: Fri Jan 27, 2012 11:32

by mauvebic » Thu Apr 25, 2013 01:59

hmmmm wrote:
As for hardware lighting, it seems that mauvebic is sufficiently pleased with BlockScape, which does have the same "sunlight shining through caves" problem as discussed. Blockscape does nothing about it but hope that the top loads quickly enough for the player not to notice, and some guessing of whether or not the player is underground.

Your move.


I can't find any kind of lighting/shadow bugs:

Image


And actually there's a whole list of features that i'm satisfied with - colored lights, real tinted glass, smaller nodes, different node shapes, vegetation that looks real, is animated and grows, realistic fires (and fireflies), animated and reflective water, to name a few. It basically boils down to how much my time is worth, 13$ to get all those features at once, or hours and days lost trying to convince you. So, feel free to find all the faults you want with it, I doubt you could beat this level of detail and ambiance.

Image
Image
Image
Image
Last edited by mauvebic on Thu Apr 25, 2013 02:10, edited 1 time in total.
"Fuck the hat." - Paulie Gualtieri
 

prestidigitator
Member
 
Posts: 632
Joined: Thu Feb 21, 2013 23:54

by prestidigitator » Thu Apr 25, 2013 02:15

hmmmm wrote:I don't mean to be offensive here, but your contribution wasn't that great anyway.
All you really did was shit up the entire existing noise.cpp with your own style of code and conventions that had necessarily broken every use of perlin noise already existing in the codebase.
Simplex noise and improved perlin noise, if we wanted, could've been had by grabbing the first free implementation off of google and modifiying a bit. Modulated perlin noise, I had implemented as part of Mapgen V7 in a much simpler and effective manner than what you had done.
I suppose celeron saw this and decided that the rest of what you've screwed up wasn't worth the minor additions either.

Oh, I updated all the places in the code base the API was used. Even fixed a few compiler warnings while I was at it. Anyway, I totally understand. Eventually you'll have enough coding and design experience to be able to understand the kind of simple interface-based design and object composition I used, and what it truly adds in terms of design potential and functionality. I can recommend some good books for you if you like, or we can sit down in IRC and do a code review so I can walk you through the code if you like. Totally my fault I neglected to offer that in the first place.
 

User avatar
Inocudom
Member
 
Posts: 2889
Joined: Sat Sep 29, 2012 01:14
IRC: Inocudom
In-game: Inocudom

by Inocudom » Thu Apr 25, 2013 03:24

For the time being, this should be put to rest until mapgen v7 is complete. All great efforts and undertakings require time and patience to pull off. Nobody here is a mighty god. Everybody here is a mortal being. While the developers strive to improve Minetest, we must learn to have gratitude for what we already have. Those that have no gratitude for the little things have no gratitude for the big things, for the big things are made up of the little things.

I too love colored light-rays and dynamic lighting, but not if they cause my CPU to burn up (and if they do require 32 extra bits, that will happen very quickly.) There are people who play Minetest that have computers less powerful than mine, so if improper coding of colored light-rays and dynamic lighting causes my CPU to burn up, you can bet that their CPUs will burn up as well. I myself do not code, but I understand quite well that coding is not a joke. It is not a game. In order to ensure that new features for Minetest do not have negative effects on computers, time and care must be taken when those features are developed.

I am never optimistic about anything, due to all of the disappointments I had in the past (and still have.) That is one of the hardest lessons I learned in my lifetime. I wish to be a person that has gratitude, not a person that is never satisfied and always wants more.
 

prestidigitator
Member
 
Posts: 632
Joined: Thu Feb 21, 2013 23:54

by prestidigitator » Thu Apr 25, 2013 06:55

mauvebic wrote:I can't find any kind of lighting/shadow bugs....

Wow! Those scenes are amazing!
 

User avatar
MirceaKitsune
Member
 
Posts: 809
Joined: Sat May 21, 2011 22:31
GitHub: MirceaKitsune
IRC: Taoki
In-game: MirceaKitsune

by MirceaKitsune » Thu Apr 25, 2013 08:27

mauvebic wrote:I can't find any kind of lighting/shadow bugs:


And actually there's a whole list of features that i'm satisfied with - colored lights, real tinted glass, smaller nodes, different node shapes, vegetation that looks real, is animated and grows, realistic fires (and fireflies), animated and reflective water, to name a few. It basically boils down to how much my time is worth, 13$ to get all those features at once, or hours and days lost trying to convince you. So, feel free to find all the faults you want with it, I doubt you could beat this level of detail and ambiance.


That looks so beautiful. And it is what I'm hoping Minetest can look like once the lighting problems are solved (and we'll have better shaders). I can understand some of the problems pointed out by the devs though... but I think we need to find ways to get this sort of thing done (the most correct way possible).
 

User avatar
Neuromancer
Member
 
Posts: 793
Joined: Tue Jun 12, 2012 22:28
GitHub: Neuromancer56

by Neuromancer » Sat Apr 27, 2013 02:54

Blockscape is jaw droppingly beautiful, but the modding interface stinks, and so there aren't any really fun mods for it. Also, I don't like wandering around in it, because the terrain is too difficult to navigate and my computer renders too slow compared to Minetest. I have more fun with Minetest, but I like how Blockscape looks. I just feel more immersed in the world wandering around Minetest. It feels more real to me.

As far as swearing at each other, insulting each other, and just being generally rude to each other... that isn't going to help the community. And the core devs are no more guilty of this than the new devs and modders. I guess I don't understand why folks can't show a little class and learn to work together. Sure sometimes a point needs to be made forcefully, and it is hard to collaborate, but this is one disfunctional bunch. Imagine what could be accomplished with a little respect.
Last edited by Neuromancer on Sat Apr 27, 2013 02:59, edited 1 time in total.
 

User avatar
Traxie21
Member
 
Posts: 753
Joined: Mon Dec 31, 2012 10:48

by Traxie21 » Sat Apr 27, 2013 12:15

^+100000
 

User avatar
Neuromancer
Member
 
Posts: 793
Joined: Tue Jun 12, 2012 22:28
GitHub: Neuromancer56

by Neuromancer » Sat Apr 27, 2013 13:06

There are a lot of bright upstart developers who have been driven away by the battles with the core developers. I think we need to look at more successful development communities and find out how they bring these new developers into the fold without creating too much chaos. Unfortunately the only way to do this is to add a little rigor to the process. That means developing a set of policies and proceedures that clearly outline what is expected from new developers like:

In order to start being a core developer you need to:
  • read our list of coding standards.
  • Suggest a small project that you would like to work on
  • get it approved by 3 core team members
  • If not approved, pick one from a list of small projects that the core team has pre-approved for work on for new developers
  • have it code reviewed for meeting the standards

We just need a roadmap. New developers need to know that they need to prove that they will work well with the core team, and put up with these standards, even if they aren't industry best practice. Once they have proven then they can follow the rules, they can start suggesting new rules.

But coming in with an unapproved massive overhaul with no clear guidelines in place is just too disruptive, even if it is brilliant and would improve Minetest.

Smoothly bringing new developers into the fold initially takes time away from actually coding, but building a strong cohesive team is worth it.
Last edited by Neuromancer on Sat Apr 27, 2013 15:21, edited 1 time in total.
 

User avatar
Calinou
Member
 
Posts: 3124
Joined: Mon Aug 01, 2011 14:26
GitHub: Calinou
IRC: Calinou
In-game: Calinou

by Calinou » Sat Apr 27, 2013 13:12

There's a TODO here.
 

User avatar
mauvebic
Member
 
Posts: 1550
Joined: Fri Jan 27, 2012 11:32

by mauvebic » Sat Apr 27, 2013 16:05

Neuromancer wrote:Blockscape is jaw droppingly beautiful, but the modding interface stinks, and so there aren't any really fun mods for it. Also, I don't like wandering around in it, because the terrain is too difficult to navigate and my computer renders too slow compared to Minetest. I have more fun with Minetest, but I like how Blockscape looks. I just feel more immersed in the world wandering around Minetest. It feels more real to me.

I have to totally disagree with those last two lines :p Maybe it has to do with processor power, but i like the improved graphics in BS, the mapgen too, not being made entirely of cubic blocks, and the view range "mid-range" stands at 136 meters, whereas in MT i had to keep it pretty low to maintain a suitable FPS. I immerse myself alot more in a world I can see :p While BS could use a basic modding API, a lot of the stuff you would have to install separately here (growing plants, mesecons, etc.) are already part of the game. Though I do look forward to being able to add textures, i'd like to reproduce Riven as faithfully as possible :p

Neuromancer wrote:As far as swearing at each other, insulting each other, and just being generally rude to each other... that isn't going to help the community. And the core devs are no more guilty of this than the new devs and modders. I guess I don't understand why folks can't show a little class and learn to work together. Sure sometimes a point needs to be made forcefully, and it is hard to collaborate, but this is one disfunctional bunch. Imagine what could be accomplished with a little respect.


People who propose changes don't come at it with a negative attitude, and in this case we were all amenable to discussing how to best accomplish it, what I wasn't ready to hear was why we can never have it. How do you negotiate with someone who's position is not to be a 'yes man'?

Neuromancer wrote:There are a lot of bright upstart developers who have been driven away by the battles with the core developers. I think we need to look at more successful development communities and find out how they bring these new developers into the fold without creating too much chaos. Unfortunately the only way to do this is to add a little rigor to the process. That means developing a set of policies and proceedures that clearly outline what is expected from new developers like:
In order to start being a core developer you need to:
read our list of coding standards.
Suggest a small project that you would like to work on
get it approved by 3 core team members
If not approved, pick one from a list of small projects that the core team has pre-approved for work on for new developers
have it code reviewed for meeting the standards
We just need a roadmap. New developers need to know that they need to prove that they will work well with the core team, and put up with these standards, even if they aren't industry best practice. Once they have proven then they can follow the rules, they can start suggesting new rules.
But coming in with an unapproved massive overhaul with no clear guidelines in place is just too disruptive, even if it is brilliant and would improve Minetest.

Developers old and new work on what they want to work on, and the things they don't want to fix they try to assign to the new guy/gal. Those devs that do both engine stuff and write mods tend to add things to the engine that expands the modding API or makes the existing mods better (ltrees, 6d, entity attach, etc). Though if you want to shoot down the new guy's idea(s) and insult them for trying, then i have a pretty good idea what they'll say you can do with the roadmap :p

As for colored lights, I can name two similar games that have it (BS, MC). But if all people want to do is copy MC without ever matching or beating it, then yes this is a waste of time.
Last edited by mauvebic on Sat Apr 27, 2013 16:55, edited 1 time in total.
"Fuck the hat." - Paulie Gualtieri
 

User avatar
Calinou
Member
 
Posts: 3124
Joined: Mon Aug 01, 2011 14:26
GitHub: Calinou
IRC: Calinou
In-game: Calinou

by Calinou » Sat Apr 27, 2013 21:52

mauvebic wrote:As for colored lights, I can name two similar games that have it (BS, MC).


By colored light, we're talking about three-channel (RGB) lights, not just coloring light based on sky light and block light levels (Minetest does that since March 2012). Minecraft does not have RGB lights.
 

User avatar
Likwid H-Craft
Member
 
Posts: 1113
Joined: Sun Jan 06, 2013 14:20

by Likwid H-Craft » Sun Apr 28, 2013 05:04

Calinou wrote:
mauvebic wrote:As for colored lights, I can name two similar games that have it (BS, MC).


By colored light, we're talking about three-channel (RGB) lights, not just coloring light based on sky light and block light levels (Minetest does that since March 2012). Minecraft does not have RGB lights.


How I change the Color RGB? or what add in the init?
My Domain's/others:
http://likwidtest.hj.cx/ (Not Done)
 

User avatar
Calinou
Member
 
Posts: 3124
Joined: Mon Aug 01, 2011 14:26
GitHub: Calinou
IRC: Calinou
In-game: Calinou

by Calinou » Sun Apr 28, 2013 09:31

Likwid H-Craft wrote:How I change the Color RGB? or what add in the init?


You can't.
 

4aiman
Member
 
Posts: 1208
Joined: Mon Jul 30, 2012 05:47

Re: [Coders needed] Colored light sources

by 4aiman » Fri Aug 28, 2015 12:05

Aha, Minetest has a feature that can't be really used for over 3 years :)
Just Puurrrrfect :)

Too bad, Freeminer has gone all "dynamic-something" approach.

No, wait.

Too bad, FM has gone GPLv3.



Anyway, the thread has started with a voice clamouring for help.
Yet the topic had twisted and now we are to discuss devs.
Everyone who does something for Minetest also does know how rude devs can be.
Everyone who does something for Minetest also does know how rude newbies can be.
Everyone who does something for Minetest also does know how a *no-no* feature turns into *yeah, finally!* after a couple of years of *pointless* discussion whether that feature is needed.



I'd say it's high time to stop discussing anyone and start doing something.
A fork can with only 1 rule to code can be created: the license should stay the same (LGPLv2.1).
But that's only suggestion.


It's no good to judge by oneself, but, hey, we all do that occasionally :)
+ How challenging it may be to start developing the Minetest engine? (Or why newcomers should be treated better)
 

User avatar
maikerumine
Member
 
Posts: 946
Joined: Mon Aug 04, 2014 14:27
GitHub: maikerumine
In-game: maikerumine

Re: [Coders needed] Colored light sources

by maikerumine » Fri Aug 28, 2015 12:50

+1
This would be amazing.
 

User avatar
TenPlus1
Member
 
Posts: 1874
Joined: Mon Jul 29, 2013 13:38
GitHub: tenplus1

Re: [Coders needed] Colored light sources

by TenPlus1 » Fri Aug 28, 2015 13:42

Just catching up on the coloured light conversation and had an idea, since default.light_max is 14 and param2 can only store a value from 0 to 255, why not split the coloured lights into hinting... e.g.

light_source = 14
light_hint = "[white|red|green|blue|violet|magenta|yellow|blue|cyan|brown|orange|grey]" -- 12 hints

..and since 255 / 14 is 18, we can have up to 18 hints if needed, but the above seems about right for any coloured lighting needed...

so, 0 is no light, 1 to 14 is white, 15 to 28 is red, 29 to 42 is green, 43 to 56 is blue... and so on...
 

User avatar
ArguablySane
Member
 
Posts: 116
Joined: Sun Oct 12, 2014 21:29

Re: [Coders needed] Colored light sources

by ArguablySane » Sat Aug 29, 2015 11:51

TenPlus1 wrote:Just catching up on the coloured light conversation and had an idea, since default.light_max is 14 and param2 can only store a value from 0 to 255, why not split the coloured lights into hinting... e.g.

light_source = 14
light_hint = "[white|red|green|blue|violet|magenta|yellow|blue|cyan|brown|orange|grey]" -- 12 hints

..and since 255 / 14 is 18, we can have up to 18 hints if needed, but the above seems about right for any coloured lighting needed...

so, 0 is no light, 1 to 14 is white, 15 to 28 is red, 29 to 42 is green, 43 to 56 is blue... and so on...


Honestly I think it would be harder to do a system like that than simply breaking backwards compatibility of the map format in the engine and writing a save file converter for anyone who wants to continue using their old maps. The lighting code needs to be fast, and determining what light value should result from, say, violet 9 mixing with orange 4 doesn't sound very fast. It would essentially need to be a huge lookup table. If each light colour channel was stored separately then they could just be treated independently and the current lighting code run 3 times.

Alternatively, if you really wanted to avoid breaking backwards compatibility, just reduce the number of colours to 7 and store them as 1-bit RGB values in the unused 4 bits of param2.
The above post and any ideas expressed therein are released to the public domain under a Creative Commons CC0 license.
 

User avatar
rubenwardy
Member
 
Posts: 4500
Joined: Tue Jun 12, 2012 18:11
GitHub: rubenwardy
IRC: rubenwardy
In-game: rubenwardy

Re: [Coders needed] Colored light sources

by rubenwardy » Sat Aug 29, 2015 20:23

In order to add colored lighting, you'd need to increase the size of a node by 2 bytes - this would be 8.2 KB per [b]MapBlock[b]. Over 1MB for 1000 nodes^2. I guess you could easily argue that this is not very much, however these bytes could be used for something else.

Here is the opinion of the developers: http://irc.minetest.ru/minetest-dev/201 ... #i_4358791

I'm just playing devil's advocate though, mostly. I'd like to see colored lighting, although I wouldn't prioritise it.
I'd prefer to see real sounds in game, more flexibility (client-side scripting, C++ mods), bug fixes.
 

hmmmm
Member
 
Posts: 47
Joined: Tue Apr 02, 2013 04:04

Re: [Coders needed] Colored light sources

by hmmmm » Fri Sep 25, 2015 21:38

Guys,
I have a better solution to all of this.

First of all, the day/night "light banks" are kind of silly - it's a feature that sounded good in theory at the time I guess but turned out to be not so useful in practice. We can omit that.

Further, we can decouple light information from the MapNode. It's not really necessary. Inner-node light only needs to be known when generating meshes. Mods that check light values are important too, but the instant-lookup advantage of the current setup mustn't take priority over an improved lighting model.

Instead, our lighting model could be to only store light values at the MapBlock borders, which makes it consume anywhere from 16 * 6 / 2 == 48 (4-bit LUT) to 16 * 6 * 3 == 288 (TrueColor) bytes of lighting information per MapBlock, depending on the color format chosen.

As an optimization, the light table can be omitted if the surrounding MapNodes have no artificial light sources. Sunlight can be reimplemented as a single overhead hardware dynamic light (TODO: determine the level of support for dynamic lighting on our target platforms)
 

User avatar
kaadmy
Member
 
Posts: 627
Joined: Thu Aug 27, 2015 23:07
GitHub: kaadmy
IRC: KaadmY
In-game: KaadmY kaadmy NeD

Re: [Coders needed] Colored light sources

by kaadmy » Fri Sep 25, 2015 22:10

hmmmm wrote:TODO: determine the level of support for dynamic lighting on our target platforms

I have a pretty old laptop(~5 years), and shaders(Or anything OpenGL in general) work very poorly for me.
I usually get around 15-20 fps with viewing range around 35.
Never paint white stripes on roads near Zebra crossings.
 

User avatar
Inocudom
Member
 
Posts: 2889
Joined: Sat Sep 29, 2012 01:14
IRC: Inocudom
In-game: Inocudom

Re: [Coders needed] Colored light sources

by Inocudom » Fri Sep 25, 2015 22:47

kaadmy wrote:
hmmmm wrote:TODO: determine the level of support for dynamic lighting on our target platforms

I have a pretty old laptop(~5 years), and shaders(Or anything OpenGL in general) work very poorly for me.
I usually get around 15-20 fps with viewing range around 35.

Would the same be true if the game engine was based on sparse voxel octrees instead of polygons? That is really all I can think of at the moment.
 

Previous

Return to Minetest Engine

Who is online

Users browsing this forum: No registered users and 5 guests

cron