These are show off pics, you won’t be able to do any of these in the real release
Rather it will be a much more realistic car racing simulator.
The project utilises many contributions like Lemur, Minie and a bunch of extra goodies that @jayfella made.
I’d love to see what fellow monkeys have in the works!
I’m working on a very basic model editor to test my asset pipeline. This way I’m quickly able to see the model structure, material parameters, animation controls, … and simply see how it will look like when imported into a JME application.
The GUI is built entirely in Lemur. I also used this project to test and try out some new functionalities, like adding tooltips in the GUI.
It was also the first time I needed to work with extra viewports to achieve what I wanted to accomplish. I’m using 3 viewports, the gui and main viewport not taken into account.
Hi there monkeys,
The last few weeks I have been exploring local and LAN multiplayer gameplay in jME.
I decided to make a game for my son and I to play against each other.
Here is a screenshot of my progress and some gameplay video.
Protyping some ideas about block world LOD for far rendering.
Far away objects in these pics are:
-castle rendered the regular way (all visible faces, etc.)
-castle with LOD prototype level 1
-weird large block pyramid thing rendered the regular way
-same object with LOD prototype level 1
This last one shows what they look like just beyond the maximum clip distance Mythruna version 1 had:
The criteria are:
must be nearly free to calculate with existing block edit data
must be low memory foot-print
must look ok from the ground and from the air
must render almost free
…probably some others I forget but those are the main ones.
So far (1) is definitely true. This can be essentially generated directly from existing world data and block masks/lighting values. Mostly. I do a pass to remove the interiors that requires recalculating the side masks or the ‘normals’ look weird… I still think there is enough there to explore.
(2) could already be improved because I’m being hacky in my buffers. (Full tex coords and normals is unnecessary… and ultimately the positions could be bytes, etc.)
(3) is ok, I think. It’s not using fog settings yet and the real fog/atmospherics will be much thicker.
(4) unknown… I have to have hundreds of them from real world data before I can worry about that, unfortunately. Since it’s using points sprites but in a funky way, I guess some cards may not like that if there are 10s of thousands of the points.
But next is trying to do an even farther version that uses a coarser grained grid.
So far, results are encouraging.
Edit: for reference in case it wasn’t obvious, v: num vertices, n: num normals, u: num uvs, i: number if index elements, ie: triangles.
Played around with a level2 reduction. Also included a point sprite version of level 0 just to help compare “apples to apples” as well as regular block renderings of the simplified block meshes that I used to feed the point sprite code.
Results are encouraging:
Like, I didn’t expect the ship to work at all but it’s fine even at the lowest LOD with 295 point sprites… considering how far away those will normally be viewed. (In this view that are scaled down by half which gives an even better feel at what they would look like from twice the distance.)
In case it’s not clear, first row: level 0, every other column is regular block geometry and then point sprite trickery. Second row, level1. third row level2.
This is probably as far as I can take the prototype without thinking about how this will really fit into world generation and storage.
It seems ok. This is all preliminary but nothing ever bogs down and I still get 60 FPS. But I’m not really throwing much geometry at anything.
The proof will be when I can actually hook it up to the real world data and detect the difference between “terrain” and “buildings” and generate these on the fly as players are modifying/building things. Still things to figure out but they seem like solvable problems.
Thanks!
Now I’m in this weird place of trying to figure out what to work on next as I expected to spend the next week tweaking and trying things. The “dumb” approaches turned out sort of better than I thought they would. There is a lesson in there somewhere: go ahead and try the dumb approaches if they are simple or along the way anyway… because maybe they will be “enough”.
Sorry to sidetrack but the sky is what I had envisioned for my world. Where there is no sun. Is the light blue stripe horizon or just a different color water?
It’s using the SimFX atmospherics-based sky (which does have a sun, we just never happen to look in that direction in these pics). The SimFX sky has an atmospheric ground plane that can be turned on and that’s what the farthest strip is… green in some directions, blue in others. For the real version, I will probably use proper atmospherics instead of the JME fog and I will probably have the ground plane reflect the sky… and the future water I create will also fade to sky color.
Right now I’m just hacking together off-the-shelf stuff like JME water, fog, etc. because I know I can “fix” the other things later.
First I heard of this. I looked it up and found your project for it.
I only see the license in the files but it looks like its your standard license so I will play around with it if you dont mind.
This looks way better than a skybox/dome. I really dislike using images since they have artifacts in them. I bet its lightning fast to as in minimal impact.
I’ve never noticed it slow anything down but I guess it is more expensive than an image.
However, the plus side is that you can use the included lighting shader for your scenery and the scenery will have proper atmospheric coloring. Bluing with distance, orange at sunset, etc…
It’s missing clouds. That’s a future project.
Edit: note: I haven’t adapted atmospherics to PBR yet but it’s really just a library call with a position and color to get the atmospheric attenuation. Something like that. Easy to add to things.
My second attempt since the first time I forgot OBS was still set at 10 FPS from when I was trying to do Blender time lapse. The original flyover was better but this one is sufficient.
MOSS (Mythruna Open Source Software) was my attempt at continuing development of Mythruna in a way that’s sustainable. So as I get closer to a new engine, parts of the suite of libraries will be released.
The idea was to keep me more organized and diligent with writing modular code, etc… and it’s been good for that. Though admittedly this proof of concept prototype is a bit slapdash as I was just trying to see if things would work or not. And it’s too easy to get side tracked by cool details. (For example, there are two ships in the simulation sailing around on their own navigating the coastlines… I wasted a day playing around with that but it’s still fun to come over a hill and see a ship sailing along…)
re: release, I still don’t have a calendar date in mind but I’m ticking off some unanswered questions that need answers before I can finish. Some answers are good, some not so good… but they all lead to an actual final feature set. This weekend, the answers were good. I think water handling is the last GIANT open question… and I’ve already done some preliminary prototyping for that. Could be I extend this terrain prototype to see what I can do with water… since I’m sure I will want to render waterfalls and stuff from far away anyway.
One of the races of Mythruna is supposed to have wings and be able to fly… so this prototype is sort of critical as to whether that can happen or not. Flying is super lame when only a postage stamp size part of the world is rendered immediately underneath you. Even for faster things like sailing ships and air ships, this far horizon stuff is kind of critical.
And it’s a balancing act, too… because the more RAM this takes, the less is available for the local block world. But on the other hand, the better I make the “far” terrain look, the less critical it is to have a super far clip on the local block world.
