Just messing around. This is a shader test that was taken from ShaderToy, converted to work with JME.
It simulates a lighting strike.
It is a simple shader that draws on a Quad. You need to supply it a texture, but I added a blank texture so it can get access to textcoords. You can supply “Color” and “intensity” to the material to affect the color mixing of white with what you supplied. This way you can get different color options when needed.
I added a control that activates it randomly.
You have hit “1” to activate the lighting.
“2” to activate it and place it at a random location on the floor.
“3” to change the color.
I added another new shader. This one simulates rain drops on the screen. Also, simulates thunder with sound and flashing of the screen with white lights.
I created a post filter to take the 3d viewport and apply the rain drops to. It ended up coming out pretty good.
In the demo you can cause the thunder by hitting a key. Also, increase/decrease rain drops by hitting keys.
The video shows me playing around with rain drops and hitting thunder. source
One last update. This is a combination of a Quad with special shader and Particle Emitter to create my Floating Gate where players are dropped into the city. The original game just had a simple door that implied you walked through.
I think the effect ended up very good looking.
First part is just in a test environment and that last 2 sections show it inside the game test environment with the shadow filter on and another with my own shader without shadows but lighting effecting how far you see.
Edit: The performance is miserable, but this is also the initial test which uses raymarching for more than 100 lights. In the next couple of days I would like to improve the performance and I would like to see if the visual quality remains.
You can become invisible in my game and walk around. This is a remake on an original 80s game, and a player would never know they where invisible as there was no indication on what was happening. So I’m thinking of adding a visual effect during the state of invisible, so the player know what is happening.
I created a little video of 3 different filters that I think might be good for the effect. the 3rd filter is just a combination of the 1st and 2nd filter together. They are simple filters, on is more of a light scatter even though there is no “LIGHT” inside the game. The other is a distortion filter, and the 3rd is a combo of the two.
Everyone, let me know what you like.
When I say there is no “LIGHT”, meaning I don’t use JME lights. Since the game is entirely based on Quads, light directions and shading do not work at all under JME. So I’m using a simple light system that I created that is done during the normal rendering process, there is not lighting filter or anything like that.
There was a TV series a while back called I-man or something and in that show they brought up the fact that if you are invisible then light cannot enter your eye… else that part of you wouldn’t be invisible. So when he was invisible he could only see in infrared.
…that’s probably too deep of a cut to use in a game, though.
In Quake when you pick the “ring of shadows” to become invisible the player’s model is replaced by a pair of floating eye balls (only for multiplayer).
So I guess in order to see the eyes are not physically changed.
Been working a lot on MOSS lately trying to get Mythruna farther along. Lots of behind the scenes stuff without many cool visuals but that’s starting to change. I’m finally getting to port the old Mythruna tree blocks to the new engine.
The only “tricky” part has been building out the MOSS toolset to allow this kind of customization.
The MOSS package includes a “shaper” tool for editing block sets and a “block ed” tool for testing them out and/or making block assets, random buildings, etc… (that’s the screen shot above: BlockEd) They are designed in such a way that applications can import them as a library and add their own custom mods.
So Mythruna has a blockset subproject and in there I can run: “gradle runShaper” or “gradle runBlockEd” to run the Mythruna-customized version of these tools… in this case with the special leaf and pine branch block factories added. It was the first “real world” test of this integration and while I had to add a few missing things, it went smoother than I expected.
…I have one more block type to port and then I can start generating trees again. Hopefully cooler pictures when that’s working.
Edit: ported the 45 degree branch block which gives me everything I need to remake the tree generators:
And the different parameterized pine tree forms supported, (16 random trees in each of the different standard parameter settings):
Shot from the ground for better scale…
Now to write actual tree generation into the new Mythruna engine. Then we really start to see some things.
Edit: by the way, taking 15-20 minutes to integrate a simple groovy script runner into my various tools has always been time well spent. Saves time again and again.
Assuming this isn’t a Stewie Griffin “How’s that novel you’re working on?” style question.
Depends on what “soon” means. This is an engine rewrite I’ve been working on for a couple of years as I build out the open source libraries to support it. So on the 10 year timeline of the whole project, yes… very soon. lol
I finished my Rain Particle effect system for my game. Just wanted to show it off. Think it came out good for the graphics style of the game.
I couldn’t use the built in ParticleEmitter in JME3.4. It didn’t do everything I wanted, so then I thought I wouldn’t extend it and just change the one method I need to get the effect the way I saw it. BOY, that doesn’t work BECAUSE SO MANY VARIABLE ARE PRIVATE. I don’t get that, I understand protected, but being private prevents programmers expanding on existing classes to meet their needs. I don’t understand why JME would try and limit people from expanding on classes to fine tone them to meet their needs.
So I had to make my own class entirely and even worse, It is 98% copy/paste from the ParticleEmitter with the change in that one method I needed but the variables I needed were private to prevent extending the class.
I also, changed the Image rotation, I wanted the little splash effect so I changed it. ParticleEmitter has 3 types, static image, random rotation, or change over time. I wanted the 1 image until it hits the ground and then rotation over time.
Also, just made a small change that once it hits the ground to stop the gravity so the rain stays in place so then the image rotation starts working and then remove.
Then I wrote my own Influencer, I need the ability to give it wind direction, this way the rain drops are effected by the wind. So the rain drops do not just come straight down and based on the wind speed it affects it more/less.
I think the end results works out just right, now time to make my snow particle effect.
private fields are more efficient and are not part of the public API. If anything, JME already has too many protected fields that we now need to support forever instead of having a properly designed class that exposed that in a different way. Extensibility should be part of the design of a class and not just “expose everything”… might as well just make it all public in that case.
Some classes are better “extended” by cutting and pasting them. In the long run, if access to private fields is needed then already you will probably be modifying a lot of other behavior also.
That being said, the built in particle emitter is a pretty poopy class. It’s been rewritten by third parties a few times and the lack of integration has been mostly political as there is a long soap-opera style drama about that.
I recommend you check the JME store for the better library. (I don’t remember what it’s called… but I’m pretty sure it’s on the store.)
After two solid days of futzing around with a world fractal I don’t even plan to use, I have a tree distribution that I don’t hate and learned a lot in the process.
I ran to that mountain earlier from this vantage point and it took 10 minutes real time… it’s far away.
Hovering at high altitude near the mountain:
From a lower vantage point and we can start to see the real block trees. I’m still just using regular JME shaders for the leaf blocks so they don’t have my alpha magic yet… which is why they get that white halo.
Because that looks really good.
