It works very similar, I’m using the WaterFilter as a base, the rest has nothing in common with the current solution
I’m nearly finished working on a small AppState that serves as a utility for switching a scene between PBR and Phong shaders, which will probably get added to my game’s settings menu as an option for ‘High’ or ‘Low’ lighting quality.
It works out of the box to convert any models that use the standard ‘Lighting’ and ‘PBRLighting’ matDefs, and you can also add custom relationships to convert between any unique shaders of your own
19 Likes
Today was one of those “code all day but don’t get to see progress until the end” days.
Started building out the new world database stuff and getting it ready for networking. The first part was to make sure that basic visuals would work and then that the world collisions would work.
The bad part of these chains is that there aren’t a lot of phases to test until it’s all together. Then when it doesn’t work you have to work up from first principles. The good thing is that usually the bugs are quite obvious. (Today I feel like I’m reaching a burnout stage because I’ve consistently been passing arguments to constructors and then forgetting to set them to anything… d’oh. Meanwhile I instantly spot other problems. (shrug))
Anyway, mesh is visualized and world mesh is colliding:
Which means this is almost ready to rebuild in a networked environment.
Is it ugly? Yes. I know I can make good looking graphics as I’ve done that. In fact, I spent way too long already perfecting that, etc… This approach is the “it’s easier to add pretty visuals to a solid base then it is to thread a solid base under pretty visuals”. It does mean constantly having to vet my choices.
For example, today I spent 2-3 hours on design of parts I won’t even build… but I didn’t know what parts I would/wouldn’t build until I knew what it would all look like.
This world is generated on the fly from sine waves. I didn’t need a real DB, or IO, etc… just something that supplied data by location. Done!
Step 1: build out the block based libraries just enough to put a game engine together (almost done)
Step 2: build a set of networked game engine components all tied together in a test app (start that tomorrow)
Then instead of adding textures, lighting, AO, etc., etc. and spending 8 hours one night tweaking the color of fire… we’ll get to AI first. Then character animation.
Save the fun stuff for last. At least that’s the plan.
The other benefit of that plan is that all of the starting steps are open source material. Once it starts getting Mythruna-specific then that new stuff stays private. So everything I’m working on now is prepping for release someday. (Hmm… maybe I should open the kimono, so to speak, for patrons…)
9 Likes
That’s starting to look pretty awesome. How do you handle maps that are exclusive to one of the shaders (metalness, roughness…)? Are you using a light probe for pbr?
1 Like
Wow amazing job, I’m looking forward to that!
Why, we would very much like to see under your kimono - as long as you’re wearing your MIT panties or some such free and open non-copyleft license 
I added a surface, but I hate it, I hate it all, so I’ve torn it all apart and started over from scratch. Here is what it looked like in case I accidentally destroy it and loose interest.
7 Likes
Not quite sure where to put this, but in case anyone needs it, the whole Substance suite is part of the Steam autumn sale currently.
Yeah, all of the stuff I’m pushing to the “moss” repo has my standard BSD license in it. (MOSS = “Mythruna Open Source Software” and is my repo for iterating all of the things I plan to release at some point… still SUPER volatile.)
2 Likes
Thanks!
The phong version of each shader just ignores the metalness and roughness maps, and the LightingConverterState stores a reference to those maps for when you revert back to PBR. So it does require that your models (aside from the Terrain) start with a PBR material, and then you can covert to phong and revert back to the initial PBR material.
And if it’s a relationship between 2 custom shades of your own, you can register the name of any MatParams (Textures and Uniforms) that need sent back and forth between the two shaders.
And yes I’m using a lightprobe for the PBR shaders. Im actually still using the engine’s “defaultProbe. J3o” probe from the PBR examples. Im still working on the best way to generate my light probes so that they’re bright enough and work as well as the default example probe.
1 Like
so its better and its worse =/
bit of surface divergence on coast lines while I’m working on “leaving behind wetness” as waves pull back, and sea foam is driving me mad
7 Likes
With FPS like that I wouldn’t worry too much about the small details. And it already looks great.
FPS is a non issue really, the scene is running 5 unique surface generators, each with many octaves of generated noise, calculated on world objects and the surface, then rendered twice per frame for good measure… While I’m slicing and dicing bits of code, it’s easier to leave it all in there and cull away what I don’t need later.
I am working on a new enemy called the Plague Spirit, and I’m also trying to focus on making the AI for the enemies in my game more complex.
The newest and most important thing I added with this enemy is reactive dodging. The Plague Spirit checks for all nearby spells, and will “Phase Shift” behind the player if it is in danger of being hit. I’ll probably reuse this mechanic for some other enemies with dodge animations, or spells that intercept incoming projectiles.
I’ve been thinking of a good way to do this for a while, and it was actually much simpler to do than I expected. I just used the Dot Product function to compare an incoming projectile’s direction with the direction between the projectile and target enemy, and that seems to be an efficient and accurate way to check if an NPC is in danger and should try to dodge.
10 Likes
Not to distract too much from the screen shots but I wanted to address this without making a whole post about it…
In case you (or anyone else) was serious about this. This is what I was thinking when I wrote that… finally got around to turning it into a more tangible idea:
…maybe it’s dumb.
8 Likes
It’s really great. Did not look at the code tho…
In my opinion, you are developing one of the most anticipated games using jME Good job 
1 Like
Thanks! I’ve probably sacrificed a lot more time and resources into this project than I should have, so it makes me feel good to hear your positive feedback 
I’m working on putting it up on Steam and will be running a beta in the near future, and then I will be offering out beta keys to any monkeys that would like to give it a try 
3 Likes
Progress has been slow, mostly due to starting a new game of Factorio after a long break …
Underwater close to done… one of the last pieces:
18 Likes
forgot to mention 2 interesting little issues I had:
- firstly my viewDirection vector, was wrong, the entire time! somehow! but does help explain a lot of odd happenings, much like dividing by w, it magically fixed a bunch of stuff.
- when underwater, the reflection cam is above water, which resulted in the reflections being wrong until I forced that camera to be “under water” in code, even though its real position is hovering above the water surface.