![[de]](/mwf/flags/de.png "Germany")
Really awesome. I can't wait to see this working in real time :). This is not integrated into Clonk yet, right?
![[ca]](/mwf/flags/ca.png "Canada")
Hmm, this is looking fantastic. I should ask, do you think will it take too much time to implement it before release?
Looks astonishing. But I said that already.By the way, I think the zoom could be safely limited to 3x (e.g. via script function SetZoomLimits) because if zoomed more than 3x, the objects start to look ugly - I keep telling the modellers and artists to "make the object look good on (max) 3x".
The shading looks better now, even though it still feels too smooth for my taste.
> By the way, I think the zoom could be safely limited to 3x
I think that's a bit too restrictive: I often zoom in a bit more than that, and most models still look quite good at a somewhat higher zoom. Also, in developer mode there should not be a limit (or a much more relaxed one), as zooming often proves to be useful for debugging.
I'm speaking of a default limit that is settable by script: See #175
Still it's annoying if you have to execute a script which increases the zoom limit every time you start a scenario in developer mode to test something. I'm speaking of the default limit if you don't use that hypothetic script function.
What about a soft lighter zone on tunnel on the boarder to sky and about a slight shadow on upper tunnel borders on the tunnel?
This still does look great, is something happening with it right now?
I've heard from PeterW (I believe; I may be wrong) it's being delayed from Release 1.
![[gb]](/mwf/flags/gb.png "United Kingdom")
Currently slowly working its way up my personal priority list. As I said, won't happen for this release.
![[pl]](/mwf/flags/pl.png "Poland")
Well, isn't it done? @.@
Looks like it's working, so I see no reason why to delay pushing it into repository....
Looks like it's working, so I see no reason why to delay pushing it into repository....
That picture is generated from a saved Landscape.bmp, which gets pre-processed quite heavily by a separate hacked-together program before getting passed to a shader. I haven't touched one line of Clonk code so far.
So, no, pushing that into the repository won't help anybody ;)
So, no, pushing that into the repository won't help anybody ;)
Somebody else might be able to work on it, though.
Playing around with shading a bit...
Attachment: light2.png - Set normals also on material with lower placement (2937k)
Attachment: light3.png - Only on material with higher placement (as reference) (2571k)
The glossy shading looks super cool imo. Not very fitting for most landscapes, but some scenarios could definitely make use of it.
You mean the first one? Hm, I have to change both data preparation and the shader to switch to the other effect, I'm not sure I would like to fully support switching...
And looking at it again - well, yes, it does look kind of cool in an artsy kind of way. Bit it definitely isn't the realistic 3D effect that was originally intended. I mean, if we end up using GLSL shaders scenarios could theoretically have the scenarios provide their own shaders, which would make a lot of stuff possible.
>light2
It doesn't look like the normals were only set on the materials with lower placement. If I look at the tunnel<->earth border, I see that the earth is lighted too. If the normals were only set on the background materials, I would only see light/darkness on the tunnel itself, no?
Does this make sense?
Both are wrong. The shading in Light2 completely ignores which material is foreground and which is background, and just produces a gradient along the edges. The reason that you don't see anything is that the Tunnel texture is too dark.
I think I once proposed(or forgot to post the picture :p) that light will be raycasted:
Sunlight shines at angle of 60 degrees to the surface, and it's lightmap has resolution of 1 light map pixel = 4x4 terrain pixels
Stationary light sources have 1 pix = 4x4 terrain pixels
Moveable light has 1 pix = 8x8 terrain pixels
The terrain would just get generic bump mapping effect basing on those.
As for the effect used currently, it could stay as it is since it wouldn't be that important anyway...
Sunlight shines at angle of 60 degrees to the surface, and it's lightmap has resolution of 1 light map pixel = 4x4 terrain pixels
Stationary light sources have 1 pix = 4x4 terrain pixels
Moveable light has 1 pix = 8x8 terrain pixels
The terrain would just get generic bump mapping effect basing on those.
As for the effect used currently, it could stay as it is since it wouldn't be that important anyway...
Raycasting sounds expensive, but dynamic lights and bump-mapping are what I want to get at. Won't be easy though.
Yeah, that is why it would be at a greatly reduced accuracy.
Sunlight and other static light casting wouldn't be that expensive, since it could be done once at start, and then just updated when a region of map it can reach is modified.
As for mobile lights... well, the only way to do it efficiently would be to use shaders, but then it would depend on GPU, which would deny the small hw requirements of OC....
Sunlight and other static light casting wouldn't be that expensive, since it could be done once at start, and then just updated when a region of map it can reach is modified.
As for mobile lights... well, the only way to do it efficiently would be to use shaders, but then it would depend on GPU, which would deny the small hw requirements of OC....
Uhm, the whole zooming technique relies quite heavily on shaders. My prototypic implementation without them was just too slow. It is pretty much decided that we will require some sort of shader support to run these effects.
Well, bitmap manipulation without shaders is pretty slow, especially when it comes to stuff that has to be done each frame...
But precalculated and then updated, straight-ray lightning should be doable by CPU.
Not that I advise doing it. Graphic cards exist so CPU can focus on calculations, and not rendering.
But precalculated and then updated, straight-ray lightning should be doable by CPU.
Not that I advise doing it. Graphic cards exist so CPU can focus on calculations, and not rendering.
Hm, currently I am thinking whether there's a place for shadows in my design (see Cäsar). Generally speaking, some precalculation has to be done anyway, so there might be a way - as long as as the behaviour can be encoded by one float per landscape pixel for all directions the light could possibly come from. Shorter shadows close to the surface or something. Not sure it's worth it.
Okay, now with shadows...
Not sure whether it's worth using a full channel for it. Would even require two channels if I made it multi-directional like the shading...
Not sure whether it's worth using a full channel for it. Would even require two channels if I made it multi-directional like the shading...
Me too :>
I'd also like some simple bump mapping and raycasted light(at least sky- and stationary...)
I'd also like some simple bump mapping and raycasted light(at least sky- and stationary...)
Would you volunteer to make proper bump-mapped textures? The actual implementation is pretty easy, my shader already supports it. The textures just look worse when I just apply some arbitrary bump map on top.
Yeah, I know it's easy, but I don't even know OpenGL properly, not mentioning GLSL itself.
Also, I am very bad at analyzing code, and don't know much C++ (oh well, I do, but I didn't use it much since I prefer Python)
I could try, but I doubt I will be able to do it.
I don't even know what file the code is in :<
Also, I am very bad at analyzing code, and don't know much C++ (oh well, I do, but I didn't use it much since I prefer Python)
I could try, but I doubt I will be able to do it.
I don't even know what file the code is in :<
That's why I was asking you about textures, not code. You know, image files. I have no idea whatsoever how to create a good bump-map.
Ah, that's what you mean? :p
Sorry, I need to stop reading everything as fast as I can....
I could try, but how would I view them, so I can see how it looks?
I thought of Blender, but it's a bit of overkill for such a simple task...
Sorry, I need to stop reading everything as fast as I can....
I could try, but how would I view them, so I can see how it looks?
I thought of Blender, but it's a bit of overkill for such a simple task...
Gimp has a plugin that lets you create bump-maps, it includes a preview as well
http://code.google.com/p/gimp-normalmap/
http://code.google.com/p/gimp-normalmap/
Well, I've had it installed since loooong ago, but didn't use it, so I forgot, thanks, I'll see what I can do...
Just re-reading the topic after some time: I can provide you with some bumpmaps for the textures in that prototype of yours if you wish.
That would be nice. The local light would be a pretty good use case.
Here is a test normal map for the sand_rough texture. I fiddled around with it a bit but I have no idea if this will look good. So perhaps you should try it out first before I make other normal maps with the same workflow (which is quite cumbersome). Perhaps I overdid it.I hereby license the following file(s) under the CC-by license
I don't like the shadow on top of the water. I think shadows on tunnel would be enough.
True, but in your screenshot, water has this texture which already suggests you're looking at it from some perspective. With the shadows, this gets even more irritating. It wasn't that big an issue with the flat water in CR, I guess - at least, I didn't even notice it back then :)
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
