https://github.com/godot-extended-libraries/mesh_lod/tree/ffac1121bac30da7a89cc6fce29cbfff12d1eeb7

Features:

• Reduce triangles
• Reduce triangles ignoring topography

Do not have the bandwith to port to GDNative.

So far the nodes are relatively organized but there is inconsistency.

I would like to see one core idea driving what category handles what. For example, there is the input category, which only has generic input, and the curve input is in curves.

There is two competing ideas there, grouping by data type, or grouping by purpose. What do you see as being a better idea.

Thinking about it, both are really fine solutions, but I would like to open this discussion.

I've only just started playing with the examples, so I might have missed something that gets the same result I'm about to outline? Anyway...

It would add a lot of flexibility if the Merge meshes node would allow for multiple inputs. As well as having an As single surface checkbox that merges everything into a single surface on the mesh, in order to minimise draw calls (I'm guessing this is much more complex than just merging surfaces - which is something I've done in gdscript before).

So for the simple tree example:

1. The trunk, branches, and sub-branches would all link their Extrude along curve outputs into Merge meshes with As single surface checked.
2. The leaves would do the same on their own Merge meshes node.
3. Then both of their outputs would go into another Merge meshes node without As single surface checked.

And now you have a single tree mesh with only 2 surfaces, which could be piped into a MultiMesh, or even just saved to disk via the inspector.

Hey @HungryProton

I'm just doing a single PR for both the Noise and Heightmap changes, as they're a bit interlinked.

Noise The noise wrapper class handles all the curve and blending stuff, and will allow us to integrate any new noise types really easily (I'm pretty keen to add some simple ones soon).

Blend Noises - I changed the second noise input to take only a single input, as you'll usually want to have separate blend amount value per blend.

Note - This noise wrapper slows down "get_noise" calls a bit compared to directly using the simplex noise. Then applying curves and blending noises slows things down even more. On my system Heightmap: Apply Noise for 1 million calls (1k heightmap) takes:

• 1.3s (1 OpenSimplexNoise direct)
• 1.9s (1 OpenSimplexNoise wrapped)
• 2.5s (1 noise with curve)
• 3.9s (2 noises)
• 5.2s (2 noises with curves)
• 5.6s (3 noises)
• 7.8s (3 noises with curves)

Heightmap Now we have:

• Create Heightmap
• Heightmap: Apply Noise
• Heightmap: Flatten Area
• Mesh from Heightmap I'm unsure on naming still, and I assume we'll eventually move these into Generator and Modifier categories?

Create Heightmap I was thinking of changing the Texture Size (renamed) and Mesh Size to Vector2, but it's extra work and I think it's better to get all my current changes merged so you can check them out. I'm also not exactly sure how to handle the mesh index for that, so if you know could you enlighten me?

Heightmap: Apply Noise I added Noise Scale and Noise Offset (which could drop the "Noise" prefix) which allows for more control over Noise blending, but it's more than twice as slow as using Blend Noises (16.4s for the same 3 noises with curves as above)

Heightmap: Flatten Area I also improved this (it was a bit buggy and changes I made broke it) I think it could do with some sort of edge blending - perhaps square and circular gradient masks?

Mesh from Heightmap I started converting Mesh from Heightmap to use ArrayMesh instead of SurfaceTool, as it's faster. But I only have code for smooth normals, so would have to workout how to do flat in order to keep the "smoothing" option (which is pretty neat to have). I think I have add extra verts and align each triangles vertex normal to it's face normal ay? Anyway, SurfaceTool isn't to slow for now.

Hey, I've got the Merge Surfaces feature working for the Merge Meshes node, with an added checkbox input.

I also changed the MESH inputs to NODE_3D and used a modifed _get_mesh_from_node function from make_multimesh which should return all MeshInstances, including multiple children.

Merging surfaces currently tries to merge in these mesh arrays:

• ARRAY_NORMAL
• ARRAY_INDEX
• ARRAY_COLOR
• ARRAY_TEX_UV
• ARRAY_TEX_UV2

But I'm not sure how to handle the case where you try to merge surfaces where some are indexed and some aren't, or some have UVs and some don't etc. I can work on this, but what's your thoughts?

I also added handling for multiple materials, by checking all three slots (material override, instance surface, mesh surface) and applying the found material to the meshes surface. This way you can later merge multiple meshes and have them keep their materials.

So to show all this off a bit more I added a new example based on simple_tree. It merges the trunk/branches with the leaves and generates a MultiMesh forest with the final mesh.

I also added a ground plane and tweaked the grass material colors a bit. See what you think, and feel free to ditch any of those cosmetic changes.

Also, let me know if I've done this pull request right, as it's my first time doing it :o

I was wondering if scaling along a curve was a feature you were considering. As an example: making the branches at the top of the tree smaller than the lower ones.

I made a rough implementation quickly, but I'm not sure if it's the best way:

tool
extends ConceptNode


func _init() -> void:
	unique_id = "scale_along_curve"
	display_name = "Scale along curve"
	category = "Transforms"
	description = "Scales nodes along a curve"

	set_input(0, "Nodes", ConceptGraphDataType.NODE_3D)
	set_input(1, "Curve", ConceptGraphDataType.CURVE_2D)
	set_output(0, "", ConceptGraphDataType.NODE_3D)

	mirror_slots_type(0, 0)


func _generate_outputs() -> void:
	var nodes := get_input(0)
	var curve: Curve = get_input_single(1, 0)
	var local_transform: bool = get_input_single(2, true)

	if not nodes or nodes.size() == 0:
		return
		
	for i in range(nodes.size()):
		var curve_point = curve.interpolate_baked(float(i) / float(nodes.size()))
		nodes[i].transform = nodes[i].transform.scaled(Vector3(curve_point, curve_point, curve_point))
	output[0] = nodes

I'm already working on this and have a prototype happening.

Currently it maps the y axis along the curve, but i'll add the ability to customize that.

What's left to do before I pull request it:

1. Fix UVS
2. have a start and end percentage along curve.
3. right now it's pretty sensitive to the curve twisting, so need to add some methods to combat that, or you get some messed up results. This will probably mean a lock rotation check box, and start end twist scalars.
4. we need a merge mesh node to make the most use of this, might work on that too.
5. taper along curve, relatively easy to add, so might as well, would be good for pre-modeled and textured tree trunks.

More ideas are welcome.

I'm getting these errors when generating Mesh from Heightmap: Can't add child 'MeshInstance' to 'Output', already has a parent 'Output'. and res://addons/concept_graph/src/core/concept_graph.gd:230 - Invalid type in function 'add_child' in base 'Spatial'. The Object-derived class of argument 1 (previously freed instance) is not a subclass of the expected argument class.

Sometimes no MeshInstance is output, and sometime multiple are output. And then eventually clicking replay will crash Godot.

Is this a threading issue? That error on line 230 seems to imply the new output nodes have been freed, not the old ones. Is it reusing references? Or do we just have to wait for queue_free to actually free the output before doing add_child again. I'm sure you know exactly what's wrong :) https://github.com/HungryProton/concept_graph/blob/9600a39c4aeecc081f2af7adf4cc07f711f7531c/src/core/concept_graph.gd#L216-L232

@HungryProton we discussed a Position from noise node here: https://github.com/HungryProton/concept_graph/pull/59#issuecomment-633555264

But is adding a separate node for this a good idea? Or should there be a Transform from Noise node that's like the Edit Transform node?

That brings me to the broader question in the title:

Should these Transform nodes (as well as the missing one):

• Offset, Rotate, Scale
• Jitter, Rotate random
• Scale from noise

be merged into nodes that handle the complete Transform:

• Transform (All) - just "Edit Transform" renamed
• Transform (Random)
• Transform (Noise)
• Transform (Offset) - just an idea, but this one could transform each node with an Additive or Multiplicative offset, based on the nodes current position from a given vector

Then could/should the individual node be removed? There's a bunch of pros and cons to this question, which I was going to list here, but wont unless you'd like to discuss them.

Note: I can work on this if you'd like?

Followed the instruction for installation on the wiki and am getting the following error when clicking on the ConceptGraph node:

In the image you can see my setup in terms of the project files. This is a fresh project and I have not edited any scripts prior to the above image.

Save a graph, close scene, reopen scene - all scalar and vector values are reset to default.

Was going to PR those noise and heightmap features, but this bug is messing up my example scene and making it hard to do some final testing.

TLDR

This change allows for Protongraph to be compiled so as to run headlessly in a Docker container. Running Protongraph this way allows a user to produce to Kafka (should they provide within the config folder a valid kafka.config and valid secrets if applicable for their Kafka process).

Detail

This change adds:

• A Dockerfile.compile to provide an isolated build process, so that the linux tool chain is used to compile Protongraph,
• A Dockerfile to run the Protongraph process headlessly in linux,
• A number of optimisations to tooling, SConstruct, and make files to properly support linux compilation,
• Some changes to the Readme to indicate how this change impacts building Protongraph.

In particular, this should allow for one to be able to produce to Kafka when running this process locally.

To compile for Docker, run ./compile.sh. Scripts to start, stop and debug the process are in the scripts folder.

To compile for OsX as per previous pull request, run make osx.

Synopsis

After this change, one can run Protongraph in default responder mode (wherein it runs locally and responds to messages from a local Godot game with sync-godot added as a plugin) or in Kafka producer mode.

Default Responder mode is best if one plans to run Protongraph locally on a single machine along with eg a Godot game.

For the more advanced usecase for running in Kafka producer mode, one may wish to model things broadly as follows:

Basically, send messages to a Signalling server, produce to Kafka, and then consume from Kafka and send messages via websocket to Protongraph (this process), then produce back to Kafka again for a Signalling server consumer to process, before sending back to the Signalling server, and then back to any connected clients.

To take full advantage of the capabilities of Protongraph when running in this mode, each and every process (save for the user-defined Client process, e.g. Godot game) should be deployed to the cloud.

Plan a Godot 4 port.

• [ ] plan
• [x] Mesh optimizer is built in.
• [x] GLTF2 module merged.
• [ ] run 3 to 4 tool https://github.com/godotengine/godot/pull/51950

Minimum flow

• [ ] Create a cube
• [ ] Test graph rearrangement

I've saved an instance of ConceptGraph3D in its own scene, then instanced it from script, and added a new Path input. Then, I call the graph's generate function.

var a = get_wire_points($poles/pole_transmission)
var b = get_wire_points($poles/pole_transmission2)
var wire = wire_scn.instance()
var path = Path.new()
path.name = "Path"
var a1 = $poles/pole_transmission.to_global(a[0].translation)
var b1 = $poles/pole_transmission2.to_global(b[0].translation)
path.curve.add_point(a1)
path.curve.add_point(b1)
path.curve.set_point_tilt(0, deg2rad(5))
$wires.add_child(wire)
wire.get_node("Input").add_child(path)
wire.clear_output()
wire.generate(true)

However, I don't see any new geometry in the scene at runtime. What needs to change in my script?

After downloading the 0.6.2-preview release, the executable fails to launch:

$ ./ConceptGraph
./ConceptGraph: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./ConceptGraph)

My system has glibc v2.27. See godotengine/godot#31950, Godot binaries are built against Ubuntu 14.04.

As a workaround, are there instructions for building the standalone app from source?

ConceptGraph becomes a full standalone software and the Addon version won't be maintained anymore Any issues that are not applicable to the standalone version will be closed when the new release will be available.

ConceptGraph started as an editor plugin but this approach quickly showed its limits. A crash in ConceptGraph would often crash the entire editor as well, and some bugs, (like the dreaded rich text label infinite loop) would just randomly appear and there would be no way around it.

Turning this addon in its own application allows for more flexibility, stability and better performance. Instead of being an addon, it becomes a "Godot game". We're no longer constrained by the editor's limits, we can easily write custom gizmos with more complex behaviors (I'm looking at you Path gizmo). But this also means we have to rewrite a lot of things the editor provided, like the inspector panel, a large part of the user interface and all the interactions that comes with it. As of today, most of this work is already done but the documentation and tutorials are missing at the moment.

This also means it's no longer necessary to use Godot to use ConceptGraph, turning it into a more general purpose software that can be used by anyone.