| Time |
Nick |
Message |
| 00:02 |
|
SpeedProg joined #minetest-delta |
| 00:13 |
|
celeron55 joined #minetest-delta |
| 00:29 |
|
Taoki joined #minetest-delta |
| 01:21 |
|
red___ joined #minetest-delta |
| 01:39 |
|
SpeedProg1 joined #minetest-delta |
| 03:22 |
|
hmmmm joined #minetest-delta |
| 04:07 |
|
SpeedProg joined #minetest-delta |
| 04:16 |
|
jyfl987 joined #minetest-delta |
| 06:20 |
|
neko259 joined #minetest-delta |
| 07:47 |
|
Calinou joined #minetest-delta |
| 08:45 |
|
celeron55 joined #minetest-delta |
| 09:34 |
|
jin_xi joined #minetest-delta |
| 09:43 |
|
Calinou joined #minetest-delta |
| 09:51 |
jin_xi |
morning taoki |
| 10:25 |
Taoki |
jin_xi: hi |
| 10:27 |
Taoki |
celeron55 (and any other core developer who is around): I need a suggestion with something in my code, and what approach to take. Not code help just asking how I should do something, as I ahve two choices... |
| 10:28 |
Taoki |
I'm also adding in a setting which will allow coloring players and lua entities as SRGB. My aim was to allow color to be per-meterial, so a segmentes mesh could have different materials colore differently. I have the code for this in place, but Irrlicht doesn't allow colorizing materials with the current lighting system. Real lighting would be needed for this to work |
| 10:29 |
Taoki |
I can however colorize the entire mesh. But if it's segmented in multiple materials (each with their own texture) I can't colorize each individually, just the full mesh via setMeshColor |
| 10:30 |
Taoki |
My colors field is currently an array. I can do multiple things now: Either I turn it into a single iColor type (instead of an array) and apply it to the whole mesh. Or I leave it an array, but with the current lighting system it will only take the first entry and apply it to the whole mesh. But I don't know when we'll get to an actual lighting system |
| 10:31 |
Taoki |
Can I keep my setting as an array and only use the first parameter? In the eventuality that someday we'll get a real lighting system so I can set material diffuse color then. I plan on doing that, but till then only one mesh color is possible |
| 10:31 |
Taoki |
Is that acceprable as an implementation? |
| 10:33 |
Taoki |
jin_xi: What do you think? |
| 10:34 |
jin_xi |
sounds good to me |
| 10:35 |
Taoki |
jin_xi: So, can I keep the colors property an array, even if with the current system only the first entry can be used? In the hope that later on we'll have real lighting and the other array parameters will be useful |
| 10:36 |
Taoki |
I guess I will then. The code to colorize materials is already there, just has no effect until there's real lighting |
| 10:36 |
jin_xi |
well, i think it should be ok, but in general i like to avoid building infrastructure before its needed |
| 10:37 |
Taoki |
Problem here is that this is a lua implementation. So the way I decide on it now might have to be final, otherwise in the future modifying it could break existing scripts |
| 10:37 |
jin_xi |
i see |
| 10:39 |
Taoki |
And if no one adds directional lighting, I plan to do it myself sometime. So later on the code will automatically come into effect and start working :) |
| 10:39 |
celeron55 |
that does sound somewhat like it'd need a more complicated data structure than just an array, in the end |
| 10:39 |
jin_xi |
but wont real lighting break any light-related scripts anyway? |
| 10:40 |
Taoki |
celeron55: Not really. I use the same example as the textures[] field. The same way textures are set to different faces, colors can be (per-material for both). |
| 10:41 |
Taoki |
BUT: The only way to do it on materials is to change diffuse color. But that needs lighting, which MT doesn't have yet. But if needed I'll try to change that myself, later on in another branch |
| 10:41 |
Taoki |
jin_xi: Don't think so, if a dynamic light source can be made to look similar enough |
| 10:42 |
celeron55 |
if what you are planning to do is similar to something that already exists, then go ahead; it can be there just for the sake of consistency if for not anything else |
| 10:42 |
Taoki |
Sure, I will then. It's set together with the textures so it should be pretty consistent |
| 10:43 |
Taoki |
Anyway, as discussed previously: The problem with dyn lighting is that it would shie through voxels. eg: Sunlight would show in caves. There is one way I believe this could be fixed, but very FPS costly. And that would be to make all light sources cut (dynamic shadows), so geometry cuts lighting. |
| 10:43 |
Taoki |
But dynamic lighting with so many voxels... not sure how much of a powerful machine would be needed. It's a later discussion either way though |
| 10:45 |
Taoki |
Plus that if you're deep in a cave and a chunk above you isn't loaded, the client would see lighting shining through there. So it's a very complicated matter :/ |
| 11:24 |
|
SpeedProg joined #minetest-delta |
| 11:34 |
|
jin_xi joined #minetest-delta |
| 12:23 |
|
xy joined #minetest-delta |
| 13:47 |
Taoki |
Got a code question. Is there some function to check if a ClientActiveObject is there any longer? I'm currently checking it the pointer to a CAO is NULL, but if the referenced object is removed while the pointer is not made null I get bad memory reads, so I need another way to read it |
| 13:52 |
Taoki |
[15:49:53] <Taoki> Issue is like this: I have two objects, X and Y. Using a declaration (like *z), X references and uses Y. Then Y is removed without being able to inform X of it. X then needs to check that Y is still valid, and nullify the *z pointer if not |
| 13:57 |
|
tango_ joined #minetest-delta |
| 14:12 |
|
OdnetninI joined #minetest-delta |
| 14:46 |
|
krayon joined #minetest-delta |
| 15:29 |
|
PilzAdam joined #minetest-delta |
| 15:50 |
|
Anchakor_ joined #minetest-delta |
| 15:56 |
|
Calinou joined #minetest-delta |
| 17:38 |
|
sstrandberg joined #minetest-delta |
| 17:49 |
|
rubenwardy joined #minetest-delta |
| 18:17 |
|
neko259 joined #minetest-delta |
| 18:20 |
|
celeron55 joined #minetest-delta |
| 18:43 |
|
celeron55 joined #minetest-delta |
| 18:57 |
|
celeron55 joined #minetest-delta |
| 19:18 |
|
celeron55 joined #minetest-delta |
| 19:24 |
|
doserj joined #minetest-delta |
| 21:54 |
|
Anchakor_ joined #minetest-delta |
| 23:01 |
|
OWNSyouAll joined #minetest-delta |
| 23:05 |
|
mrtux joined #minetest-delta |
| 23:09 |
|
OWNSyouAll joined #minetest-delta |
| 23:10 |
|
te3 joined #minetest-delta |
