I have parametric growing trees that are currently made up of cylindercones (my custom TCastleCylinder with top and bottom radius) and spheres (for knuckles to fill gaps between cylindercones that are at angle). These trees are taking more memory than I would like… 200 trees that grow to have 4 branches runs out of memory. I was thinking an extrusion would both look better and be more efficient in memory. The whole main trunk could be one extrusion with each branch being one extrusion.
Are there any examples for using the extrusions? Do you have plans to wrap extrusions into a castle primitive like you have for Cones and Cylinders or just leave it at the x3d TExtrusionNode level?
But admittedly, Extrusion is not a way to save memory. Extrusions are internally just converted to meshes, since that’s what GPUs understand.
We don’t plan to expose extrusions (the X3D TExtrusionNode concept) in more “friendly” way at this point, I have to admit.
Extrusions in X3D turned out to be quite complicated for people, and they don’t cover a lot of practical cases. In most cases I saw people using extrusions, eventually ended up wanting to “escape” the constraints of the extrusion… E.g. to make a tree trunk from which numerous branches diverge. This is trivial to express as a mesh (and when designing it in Blender, you would indeed use Blender’s “extrude” operation a lot) but it doesn’t fit into X3D Extrusion.
So the practical advise for people using extrusions is to use the “extrude” operation in Blender. This is flexible: it makes an extrusion, but just by modifying the mesh, so you can switch between thinking about extrusions and not freely.
So we don’t push much for using Extrusion X3D node. That said it exists, we support it following the spec, if it fits you – go ahead and use it (you can put TExtrusionNode into TShapeNode and load it into TCastleScene).
I thought it may be more efficient since I wouldn’t need the spheres at each node just to fill any small gaps between cylinders. And perhaps having one object from root to tip of tree instead of many cylinders and spheres would be more efficient. The trees are dynamically generated, growing from ‘seed’, so not modelled in blender.
So now that tiled terrain has repaired itself, I am back to my trees because they are broken when I accidentally deleted my custom cylindercone code that enable both top and bottom radius at same time. From what you said, it seems like you disrecommend using the x3d extrusion node and building a mesh? I want something like the math shown at OpenGL Cylinder, Prism & Pipe ? My current trees take too much system memory because they are built of too many objects, so for primary branch from trunk to tip in a single mesh would be pretty nice, then the same thing at small scale poking into that for secondary branches. I want to have forests, not trees, so just the data for my trees using my cylindercones and spheres for the knuckles is way to heavy. Maybe I am trying to do too much without billboards and should just build the tree out when very close. I don’t use blender for these, it all has to be calculated. I had hoped to get some mileage from x3d because it seems like a lot of work to implement these pipes from scratch. If I do come up with something for pipes with a radius at each point, I will share it here because it seems like a very handy primitive.
The geometry on OpenGL Cylinder, Prism & Pipe is exactly the Extrusion from X3D So if you want exactly something like this, I’d say to go ahead and use X3D TExtrusionNode.
It is limiting. I.e. the resulting mesh must have the Extrusion “structure”, i.e. cross-section extruded along the spine, you cannot make an exceptional topology (e.g. denser or branching) at some point. And low-poly / quality tree models for 3D games usually have branches grow from trunk, splitting the mesh into branches. So you cannot express such trees using TExtrusionNode, you need a full mesh for this.
This may be useful or not useful advise to you, depends on how you plan to make trees. I admit I would not try to generate trees myself, I would rather use some tree generator, get e mesh in Blender, eventually improve this mesh in Blender, and then export it to glTF. If I would need variation, I would make 10 such models, and then at runtime randomly adjust scale a bit.
This is not a way to conserve memory. In the end, each TExtrusionNode is converted to TIndexedFaceSetNode, so a regular mesh. To save memory, I’d experiment with billboards and/or TCastleTransformReference ( Viewport with scenes, camera, navigation | Manual | Castle Game Engine , see also how examples/terrain sets up trees).
All in all, I’d say that if you want something exactly like on the screen you attach, and the limitation I described doesn’t affect you – then use TExtrusionNode, there’s no point in reimplementing this on your side But it may not change your memory usage, if this is the issue. For this, test TCastleTransformReference .
Thanks, that will make building a pipe MUCH easier. Branches can be separate objects. It will be far better than my current trees which made of many pieces and spheres at the knuckles/nodes in the tree to fill gaps. Branches as separate objects they can also then be dropped quickly as detail drops.
I want my trees to grow dynamically based on environmental factors and be individual and look realistic and diverse when close and gracefully lose detail as you get further away until they merge to forest when far which then doesn’t use models at all, just my water/vegetation mesh.
Here is a good screenshot of what I have in mind from before I broke the trees. All it really needs is perhaps some billboarding in the medium distance. This combines both the tree models and the water/vegetation layer to show the trees. Ideally would use only the models in the foreground.
The trouble with trees is that data size grows exponential with each branch. So every bit counts.
So if you want exactly something like this, I’d say to go ahead and use X3D TExtrusionNode.