A texture is also an asset loaded via the asset manager.
The quad faces in Minecraft have primitive textures on them.
But that’s not the point.
The point is:
Typical games load complex models and levels (made in Blender by artists).
Minecraft-like games generate almost everything in code (generated at runtime).
Block worlds are not made of blocks. If you search the forum for that you will get a million hits. It used to even be a tooltip if you hovered over the word blockworld anywhere in the forum. Every bit of land you see is a custom mesh of quads (in Minecraft’s case).
Where as for a standard game, you create a level in Blender. Load it. Create some mobs in Blender, load those. Turn on bullet physics… and now you are already halfway there. Even your lighting is probably already built into the level… and you’ve certainly baked in AO or something.
For a block world, you have an algorithm to generate the world. You need to generate the mesh for the land. You have to do your own custom physics stuff to make things play nice with the custom meshes. You have to do your own lighting. etc… basically nearly everything is from scratch.
The only external assets Mythruna loads are the avatars (and eventually the mobs). Everything else, even the tables and chairs, are generated from blocks in game. In Minecraft, even the mobs are generated from blocks.
Block worlds are not made of blocks.
Life sounds like a lie…
Yeah, I understand, thanks for the info.
I was trying to figure out where my projects fall into. What I’m doing now seems to fit more with these “Blockworld” type games when it comes to how it’s setup.
I was just trying to see where the line is drawn, but I guess I understand it a bit more.
Thanks for all of the help 
.
So you custom generate every mesh from some raw data format? Like you place all of the triangles yourself?
From some of your posts so far, it seems like it’s not clear you understand what we mean.
Some of the stuff I’m doing currently. currently was being custom meshes, but I think I’m able to change that. Some is, some isn’t.
I just wasn’t sure, as I mentioned in my last post, what the “Fine line,” would be between the 2 types of data generation, or whatever you want to call it .
It seems you can load assets, or have them preloaded, but what you do with them seems to be the issue. Either load up a world, and some meshes (level, models, etc), or load up a textures and manipulate those textures into some sort of custom mesh, terrain, and such. But the comment about adding an item like a sword was interesting, because you’re just using the sword with another model, or is there more to it than that and combining the 2 models is considered a “custom mesh?”
Right?
Thanks.
I’m starting to get the feeling that there is a troll among us…
? I only repeated what you said .
Please google “jmonkeyengine custom mesh”.
Read, understand, memorize.
In Mythruna, a sword is made just like the world. Code that looks like:
Mesh m = new Mesh();
...build the arrays...
...set them to the mesh...
...create a geometry object to hold it...
Never once ever is there an assetManager.loadModel() for any terrain or objects or items.
So, if you call new Mesh() and are populating it with your own data then you are building a custom mesh. Else you aren’t.
Thanks for the information. Maybe I was getting confused with a “sword” in Mythruna, and a sword in a regular game, since Ogil’s comment seemed to indicate swords and armor in general, but maybe it was meant towards “Blockworlds.”
Wouldn’t a normal game call the sword as it’s own model, and just attach it at some physics point, to the “Character model”, and then run animations and whatnot on it for what he runs, swings, etc?
So, if you call new Mesh() and are populating it with your own data then you are building a custom mesh. Else you aren’t.
Thanks, that’s what you mentioned in the other topic, but I was just curious when you should, and should not do a custom mesh, sorry that I’m not making much sense in my questions. I should go eat 
Such as why you couldn’t just call the sword itself into the world, or because it’s a “blockworld” the sword itself has to be made “blocky” or whatnot, whereas a normal game you would just generate the sword as I mentioned above?
Thanks.
Because the swords, tables, chairs, etc. can also be constructed in game. Players have made everything from toilets to baby grand pianos.
SO that’s specific to the type of game then? I’m not that familar with Minecraft and the abilities of Blockworlds, but I have heard people making their own things, so that makes sense.
I was looking at it as “why would I have to make a custom mesh of an already made model,” but I guess then that’s in a normal game, and I guess “normal games” don’t do much in the way of “custom meshes,” which is why I was confused… Or maybe still am… lol thanks!
IIRC correctly, in Minecraft the tools and weapons of the avatars are generated from textures - empty alphas are little holes and non-empty alphas are a custom mesh generated at runtime.
And yes, in any other game, you would load a sword - maybe combine some variations for the different parts of the sword (e.g. Gothic 3 had a “sword generator” that uses different variations to generate several sword visuals - similar to the “Bazillion guns” generator in Borderlands).
Minecraft-like games are a special kind of game - not the usual way to make 3D games. There are many new similar games like “Planets³” (“planets cubed”). They use a similar voxel-based technique.
This makes it sound like generating a mesh is hard. Especially for something as geometrically simple as a blockworld, generating a mesh is trivial in my experience. I admit that my experience is not extensive, but I did some mesh generation as one of the first things I ever tried with JMonkeyEngine and it was not an issue. Why would it be?
Custom physics sounds hard, but not when your environment is represented in an array and you just need to check whether each array element is passable or impassable. That sort of physics is not only fairly easy, but should also be much more efficient than any more general physics.
An algorithm to generate the world is very hard, but also surely optional. Not every Blockworld game needs to be procedurally generated.
Please correct me if I’m wrong because I’ve only scratched the surface of Blender, but Blender seems to be focused on modelling scenes that are visible all at once. That’s excellent for modelling furniture, enemies, or even whole rooms for a game, but surely not whole levels. Surely one doesn’t want to load every mesh that will be used anywhere in a level all at once as a single Blender model, including things that are nowhere near visible from the current point of view.
Does Blender have some way to divide a scene into regions so that we can load the relevant regions when they become relevant? Does Blender accommodate variable level of detail so that parts of the level don’t need to be rendered in full even when viewed from far away?
I believe I read something in one of the JME docs that essentially what’s out of the viewport/cam frustrum isn’t rendered (or rendered off-screen separately), and that doesn’t impact what’s going on in view.
It seems to make sense, because there would have to be calculations on our part where “Room 1 part A” goes, and where “Room 1 Part B” starts.
Instead we can import everything and the engine will take care of it itself.
I’m pretty sure I proved this true when looking at part of my world that caused a slowdown, while turning away from it, would speed things up.
I might be wrong, in which case hopefully someone can explain better.
Because you know, we can’t have trolling on this forum…
From experience, 99% of the people who try to make a block world struggle with this first step. They try to make a world out of 10,000 JME Box objects and wonder why there app is slower than minecraft.
Doing this optimally is non-trivial. Doing it non-optimially tends to be unusable. For anyone who doesn’t already know about things like triangle winding, they have a HUGE learning curve.
That would depend entirely on your game.
There will always be some tweaking.
The point is that you can get very far with very little knowledge by loading models and letting the engine do the work for you. Compared to a block world where you start everything from scratch on the first line of code.
That makes me wonder how one would render a mountain in a blockworld. Often Minecraft lets you look at mountains in the distance, but obviously one wouldn’t want to put millions of triangles on the screen just to render a distant mountain. One should rise above the blocks and generate a mountain-shaped mesh with an appropriate number of triangles for what is being viewed, but it’s far from obvious how one would do that.
And if I understand what you are saying, this is what we mean when we say that block worlds are not made of blocks.
They are made of meshes containing only the visible surfaces (quads). The algorithm itself seems deceptively straight forward:
for each non-empty cell {
for each neighboring cell {
if empty, add a quad
}
}
The devil is in the details. “What about neighboring chunks?” “What’s an efficient way to accumulate quads for the final mesh?” etc… then you can also get into even more optimal solutions like greedy meshers.
Actually I was thinking of rendering a distant mountain as mesh in the shape of a mountain rather than a mesh in the shape of a mountain of blocks. There’s no point in rendering blocks when the blocks are too small to see.
Even so, I see your point that there can be an issue with even merely rendering blocks. While you can create the mesh in many ways, there’s tons of room for additional sophistication and optimization that goes way beyond avoiding making triangles on the inside of walls.
I imagine that the focus should be on the vertices, not the quads. The first job of making a mesh is a list of vertices, so in a blockworld I would start by generating a list of all surface vertices. If the world’s not too big a full scan of the world could get that, but otherwise a breadth-first search might be better.
Once we have the vertex list, I’d scan every block touching each vertex and do a count of the number of triangles needed for each one. Using that we can allocate the triangle array and with another scan we can fill it.
And if we want multiple materials we can just do a separate scan for each material to give each material its own mesh.
In a typical block world, about 80% of the vertexes and quads are never seen.
Definitely better to just emit quads… even in a greedy mesher you merge quads. Vertexes are basically irrelevant. Other than in a greedy mesh, they are not shared across quads. They can’t be because they have different normals an different texture coordinates.
Anyway, the point is already made. It’s an advanced topic and yet 90% of beginners immediately want to start here.