Sdfgeoff's node shaders and other experiments

I’ve visited your page before…I think this is great and can’t wait 'till I see the physical prototype…what not…you do all your own engineering as well…e.g. milling(lathe) sheetmetal work etc…this is really interesting stuff for me…I grew up in a jack of all trades home and have done a lot myself…just never inclined to be a ‘maker’ or creat robotics…please show and tell more…

The atmosphere game idea looks fun. If you need help with asset or audio design - shoot me a pm.

I’d still love to work on the atmosphere game, but I never actually figured out the main gameplay idea. There was a cool mechanic (scanning through walls), but I couldn’t figure out how to make that into something that the user would find fun.

If you have some ideas about what a user could do in that sort of game, I’d really like to hear them.

1 Like

Shoot me a pm?

I was working on a space game. I planned to make it in Godot, but was fighting their shader system. So I implemented the shader in BGE nodes first, before implementing it in Godot shader code. Here’s an image of the blender version:

What’s quite cool is that with the same shader you can simulate many different planet types. For example changing the atmosphere tthickness, atmosphere color and ground color (same texture and shader), you get:

Or even:
planet3

I chucked it in the sun from one of my previous BGMC entries, and a little spaceship, and…


Unfortunately, blender doesn’t allow enough variables into Node shaders for me to control this shader how I’d want to.

Of course, I did end up implementing the shaders in Godot:


But I still prefer the blender implementation.

The implementations between blender and Godot ended up being quite different. In blender, I took a lot of artistic license. I knew that there was going to be a fixed viewpoint, and a single source of light. So it messes around with the light vectors. However, in Godot, the implementation is more “real” and as a result, gives good results from any viewpoint, and even with multiple lights.

Anyway. Final image for now (in Godot):

3 Likes

Dude iam desparate need of one of your shaders my stuff looks crap so far
:joy: Seriously!

I need a fade like effect when approaching and going far away from a particular object !

Fred/K.S

The camera data node has a “view distance” parameter. The trick is that it is the number in blender units. So by default, objects closer than 1.0 blender units will fade out. To make it further away, you have to multiply it by a small number. Eg multiplying it by 0.1 will make the objects gradually fade out to 10 blender units. By subtracting, you can make it fade out further away (multiplying both moves it further away and makes the fadeout more gradual)

So for example, this crease quite a nice technicolor effect centered on the camera:


You can turn this into a fade, either a normal one, or by combining it with a texture, perhaps one with a fancy edge:

Blend:
Fade.blend (797.9 KB)

2 Likes

Ok i’ll try it thanks @sdfgeoff yr AWESOME !!!:sunglasses:

Fred/K.S

So, I’ve lazily been working on a 7DFPS entry. I probably won’t get it done because I’ll be pretty busy for the next few days, but here’s what I’ve got:

A spaceship:

A hud:

I see you asking about the fans on the side of the ship and the ice on the HUD? Yeah. You’re going to be playing … freeze tag: essentially a “normal” space-ship shooter, but enemies can revive each other. (Yes, the ice on the windshield goes away when you’re not 2 degrees above freezing with your engine only outputting 31 watts)

The code for the HUD is tested and working, as is various other code such as guns, damage, etc. However, it’s just in test-form at the moment, so you can’t really see anything interesting.

The levels are an interesting afair because the procgen challenge is also on this week, so I thought I’d try procedurally generating levels. While I have yet to develop the actual generation, I’ve implemented a method of representing the levels (I’m calling it “walled voxels”) and converting them into in-game geometry.

Probability of finishing this whole lot by the end of the week is approximately zero, but hey, it’ll be fun.

1 Like

I recently had a game idea, and wanted to do a mock up of several things. So I made a small scene in blender to test some visual appearance ideas and user interface.
The idea is that you are the gunner on the green spaceship in the middle of the screen, and you can assign the weapons (in this case the two lasers you can see icons for at the bottom of the screen) to targets (the red cube). You can rotate the view with the mouse button, and the spaceship can spin and head whatever way it likes without affecting your view.

I tried to mimic a sensor-point-cloud for the visuals, and when you play the game the dots slowly animate and fade in/out.

1 Like

A couple months ago I drew this concept art as part of a 30 minute spitpaint:

I decided to have a shot at making it in vanilla BGE 2.79 using assets I’d made over the past few years. Here’s a clip:

Here’s a picture of the ship. Yeah, I pulled it from some of my previous game demos (I also used it in a BGMC at one point)
ship

The skybox is a new setup - though it’s based on my normal lighting setup and use of a gradient mapped onto a sphere. The difference is that this one is keyed in to the scene lighting, so the sky color changes to fit etc.

The trails behind the ship are interpolated on the GPU as per various previous demos I’ve made. I had to fix a few issues to deal with teh fact that these player vehicles travel really really fast. It may seem slow in the video, but in “reality” they’re doing above the speed of sound. They’re doing about 500m/s (1800kph), it’s just that the terrain is some 100km square and not very detailed.

Will I work on this game any more? Who knows. Probably not. Maybe I’ll add a course for the player to fly around.

All blend file are available for download from my github.

3 Likes

i assume you must be moving the world origin close to the player to prevent precision issues? 100km is a lot of decimals to drop.

I’m not. I mean, I should, and precision issues do become noticeable if you fly too far. But if I were to continue to develop this it would be into some sort of race where the player doesn’t go further than a few km. As a result the mountains are just a fancy backdrop and the player wouldn’t get far enough for it to be noticeable.

A much bigger issue is Z-buffer. With a sight distance of 25km, anything closer than ~0.1bu quickly starts z-fighting. So I think I’d have to do the cockpit interior in a different scene and use a RenderToTexture to stick it in front of the camera.

Hmm, I wonder if I could use the viewport feature to render the scene overlayed on itself - render it once from 500m-25km, and overlay onto that 0.01-500m. I may give that a try…

1 Like

i use a clip of about 0.1 - 100km and i dont get much zfighting at all

yeah true Z fighting is a real issue in UPBGE!

Fred/K.S