Tehuelche v0.2 (Full C# & GDI+ Voxel Space Engine)
Vložit
- čas přidán 20. 06. 2024
- Level 2 of Tehuelche is taking too long to develop, but I really wanted to show you the reflection effect I've been working on. I'm pretty satisfied with the result so far, although not completely.
What do you guys think? - Zábava
Water effect- prima sort!
Thanks!!
Wow great job. Love the shimmering water effect
Oh... that's the only thing I can't take credit for. It's an animated texture I took from one of the Div Games Studio examples from back in the 90s.
Very nice.
Thanks!!
Está muy bueno, me pareció interesante también el seguimiento que hace la cámara al helicóptero. Excelente.
Gracias, loco! Igual el movimiento tiene un problema que todavía no pude corregir, y es que girar quedó atado al frame rate. Cuando se arrastra un poquito, se nota, y gira más lento. Pero bueh, como varios proyectos usan el mismo código, tengo que entrar con pinzas a tocar ahí.
@@adrikriptok7225 calcular el deltaTime entre frames no te funcionó?
@@LordFers Sí, sí. Para casi todo lo que es movimiento lo uso.
(Por cierto, recomiendo fuertemente este video sobre el tema: czcams.com/video/yGhfUcPjXuE/video.html, mirátelo si podés, está muy bien explicado)
El tema es que cuando programé la interacción del mouse (uso el mouse para girar al helicóptero y la cámara) no supe cómo incorporarlo (o me olvidé, ni idea), y como la mayoría de las veces no se nota, lo dejé así... durante años... Y bueh...
Very nice effect! And music choice haha
Thanks, man! I know the effect can still be improved, and I always get great ideas from the comments section (like the improvements we talked about in my environmental mapping video, although I never could make it work perfectly for nearly horizontal polygons that reflect the 'poles' of the skybox), so I just posted what I had.
And yeah, that soundtrack is ESSENTIAL for a video like this!
@@adrikriptok7225 oh I wanted to ask, is this terrain engine similar to the one Leo did?
Hi, man.
If you're talking about this video czcams.com/video/d1MVZukvP_w/video.html, not really.
In Leo's voxel engine, you have a predefined max depth by a fixed number of scanlines. Most voxel space engines work like that (it all comes back to Comanche). With this approach, the rendering is much more stable, but you cannot have the camera too high because the "end" of the rendering space would be too apparent. You have to keep the camera close to the ground.
When I made this voxel engine, I thought about using that approach, but I wanted to be able to raise the camera over the mountains and still be able to see the terrain to infinity (don't know why, now, it seems like a pretty stupid decision, but here we are). So my algorithm is the same as painting a flat texture, like Mode7. That's why far back there's a lot of flickering. But I can have the camera as high as I want and still see the terrain keep repeating until infinity.
I could reduce the flickering by sampling the terrain as if the "mode7 plane" Z = 0 were far lower than the camera (let's say Z = -50), but it would obviously harm performance. So I would also have to set a "max depth" to compensate, and then I'd probably get a result more like Leo's.
@@adrikriptok7225 Oh ok. So it's like rendering the mode7 plane, except for each pixel on the plane you calculate which cell of the height/color map you need, and then render a vertical column with that height? And the height would be divided by Z or something?
@@fuzzycat3651 Exactly! In a Mode7 plane, you just sample color, but in this case, it's color and height. Then you make the necessary calculations to plot the column correctly (dividing by the distance to the camera, adding or subtracting the camera height. You know, the usual).
Very cool water effects! The glimmer is very neat. It was unexpected that Comanche actually had a shimmer effect on their water, so it's nice to see here as well. The reflections work well, also. The lack of mip-maps showcases the retro feel of the terrain, though even the original Voxel Space used mip-maps -- but I never for my original engine, so this feel more at home for me. But there's a lot of flickering, since the colors change drastically from voxel to voxel. I wonder what the size of your map is? I could render it in my engine if you sent it my way. I see the mountain reflections in the water have the depth cut-off, earlier than the terrain itself. Once you add mip-maps, you can extend this very far quite easily. Nonetheless, this is pretty kick ass. You have a polygon engine in the terrain, with proper Z-buffering, as well as some game components. Thanks for sharing.
Thanks, but the water (and the shimmering) is something I cannot take credit for. It's just an animated texture I took from one of the Div Games Studio examples.
The flickering, sadly, is because I'm not really using the same algorithm as Comanche. I'm doing something different that depends too much on the resolution. It has pros and cons, but in this map specifically, it is very noticeable because of the high contrast (both height and color). The previous level was more uniform and soft. I didn't know the original Voxel Space used mip-maps. I've thought about it, but I can always add them in the future if I don't find a better way to improve the visuals.
My maps are 4096x4096, but they don't tile infinitely like the ones in Comanche (yet). You can find the map in my games repo. The code is not up to date, but I just updated the texture and height maps if you want to check them. github.com/adri-kriptok/games/tree/master/Kriptok.Tehuelche/Scenes/Map00
The 'depth cut-off' effect is because those mountains are beyond the horizon (the horizon created by the curvature). The terrain is drawn front-to-back, so I start rendering off-screen and don't think about the horizon when drawing. But the reflections are rendered back-to-front, so I have to give it a 'starting scanline,' ergo, I start rendering reflections at the horizon, ignoring what can be beyond (It's clear I don't have everything figured out yet).
About the Z-buffering: it's not that proper. The terrain occludes the objects, but the polygons don't share a 'z-buffer.' All the polygons of each object are drawn together (sorted by the painter's algorithm), except the ship, where every polygon is independent (required because of the size and the superposition with the turrets). Having a proper Z-buffer would drag the performance.
@@adrikriptok7225 You know the cause of flickering very well, as I've experienced both. At extreme height changes, a ray can pass through a corner, and make it even worse. Mip-maps are your first order to correct, but it doesn't fix large changes in color/height from voxel to voxel. To solve that, you'd need to step through the voxels during the ray cast at a smaller step, or even compute where they end (like you would in Wolf 3D, if each voxel was a tile in a room).
@@adrikriptok7225 I don't think you have curvature, do you? So you just cast the ray to a set distance, then stop? In my original 1995 VGA engine, I also didn't have mip-maps, but I stepped larger in the distance, which causes more flickering, but allowed me to render further in the distance with the same work. However, mip-maps would've reduced flicker, and reduce caching issues -- speeding up the engine.
@@adrikriptok7225 I "cheat" in my software engine, since the GPU naturally gives me a Z-buffer. Since our algorithms naturally have a Z buffer, I give it to the GPU. Therefore, my sprites (or your polys) would render correctly, effortlessly. However, I devised a software solution without having a Z-buffer which I was going to implement (but never did) in my 1995 VGA engine: you only need to record the height of each hill -- just as I do in my Pseudo 3D road engine. Then that's your clip range (like the edges of the screen). But it differs per-column, so render your sprites (or polys) per-column. :)
@@JDoucette That's what I'm doing. While rendering the terrain front-to-back, and when I have to render an object, I calculate the 2D bounds of the object (the rectangle) and compare it with the current height buffer.
If it is totally visible, then great, I save it in a new list and continue. If it is not visible at all, I do nothing, and if it is partially visible, I save it int the same list, but also save the status of the height buffer (for the horizontal bound of the view).
Then, when the terrain is done, I just render all the views saved in the list, occluding the bottom part when necessary.
quiero ese juego ya!!!!!!
😄😄😄😄
Se agradece el entusiasmo, pero le falta tanto...
@@adrikriptok7225 por que esta buenisimo.
Curious how you are generating your terrain height & color maps?
I'm using Bryce 5 now. It's a bit old (and the terrain editor is limited), but the terrain fractal algorithms are great.
Sadly, the process has a few problems. For instance, exporting the heightmap works perfectly, but the textures don't look right and don't have shadows, so I have to render the terrain with the camera on top and save the result as a 'texture.' However, it can only render in 4000x4000, so I have to stretch the texture to 4096x4096 to match the terrain.
It is very tedious, and the results are far from perfect, but I'm just having fun after all.
@@adrikriptok7225 I remember Bryce. I don't think I ever used it. I can see it makes fractal terrain. I wonder if it has erosion effects. I'm guessing it does, and that would add a lot. The 4000x4000 max resolution is curious. Does it make seamless terrain (infinite wrap)? How are you adding lighting/shadows to it? Lighting is fairly easy to do, but shadows needs more effort. This is an area GPUs would help.
@@JDoucette Yeah, it has erosion effects and works pretty well (I think, but I'm not a geologist).
The shadows are added by Bryce. Maybe I wasn't clear enough, so I'll try to explain again:
Bryce has an "export" option, but it exports the terrain (the 3D model) and the texture without any light or shadows, so when you add the object in a 3D environment, it is affected by the current ambient light (which makes perfect sense).
But for a game like this, I have to do it manually. For example, the height map is easy: I just copy-paste it from Bryce to any drawing software and save it as a PNG. That's the easy part.
For the texture, in Bryce I have to position the camera on top of the terrain looking down (trying to match the corners of the terrain with the corners of the render area) and then render it (with shadows and everything). That render is a maximum of 4000x4000, so I have to stretch it to 4096x4096 to match the height map exported previously.
I hope that's clearer. And no, there are no seamless terrains in Bryce that I know of. And even if there were, the way I'm rendering them probably wouldn't look right anyway.