Terrain 3D, Scattered Models does not use object origin

Eldarduil · October 30, 2026, 8:04pm

Describe the bug

Today I was playing with scattered models. So I noticed some issues with it.

First I noticed for Leafy Forest prefab has Trunk collisions are offset. It is not at the location of the trunk. It is a bit on the side.
Then I check the code of the DefineScatterHelperClasses and I realised it creates the TrunkTriangles at the center of the object (bbox).

This is very problematic when you use a tree model with asymmetric canopy, such as “Common Tree 1.glb” in the Leafy Forest prefab. Because, now the trunk collision is at the side of the model’s trunk instead of the trunk’s real position.

Also when it comes to the scattering logic, I understand the some reasons to use bounding box center instead of the model origin. such as density spacing etc.

But again when we have a tree model with asymmetric canopy, in some cases it causes that all the trunk base is floating on the slopes, instead of half of it should be floating if the scattering done from the origin.

Of course correct way to handle the floating trees is the extending the trunk base below origin point. OH! wait! scattering uses the object center not the model origin so we are never able to fix that.

Well… I guess these explains how scatter model object limits the developer because it work in certain models.

Suggestions

So, all scattering logic and trunk collision creations should be done considering the model origin not the bounding box center, Like a real 3D game engine or 3D modelling software.

It is not a good practice simply ignoring accepted modelling, exporting, designing principles when implementing new features to the engine for the sake of ease of use. I say this because I believe it was a wrong thought that says “hey we can’t guarantee if the model has proper origin point, so better to use bbox center or else people gonna have bad time” or it was just Claude code’s slopy unnecessary idea that AIs usually invent from their arses.

Guess what? now people that know proper game development practices, has a tool that works against them and limits them into using spessific 3d models.

Bonus:
It is so crazy that Gdevelop is Z+ Up game engine, but Scattered Models are only accepting Y+ Up models… why? I am sure because the gd asset store is full of Y+ up models…

Eldarduil · November 6, 2026, 3:56pm

This should be taken seriously.
Currently calculating object bottom center and following the same method in all scatter logic is awfuly wrong. Which causes misaligned Trunk Collision locations and floating objects on slopes. People could have strange asymmetric objects to scatter, not only the perfect symmetric ones.

Deciding where is the object center is not Game Engines decision alone. User can decide by placing their 3D model accordingly before exporting to glb. Which is a normal workflow in game development.

Bouh · November 6, 2026, 5:29pm

Would you be available to test this change in this version of the extension?

Terrain3D.zip (61,3 Ko)

Eldarduil · November 6, 2026, 7:20pm

Thank you for adressing this issue.

I confirm that your changes fixes the issues.

The tree with white trunk is Zup exported model. The other one is Yup model from Leafy Forest prefab. As you can see because it is placed at the origin, trunk base is clipping trough the terrain which is exactly what is needed to prevent floating objects. and with that it automatically solves the trunk collision position is not at the object’s origin position. Great!

This is impossible to achieve if object bottom center is used, because no matter how high you place the origin from the base of the trunk, the model will be pushed up and it will be still floating.

Example down below shows that you always extend your model below origin point so when it is placed on another objects angled surface you are preventing floating objects. this is well known common trick.

Anyway,
I really appreciate your care on this situation and your elegant solution by adding dropdown options is so good. Thank you.

But I am not done with the new Terrain3D extension issues
For example; It does not expose the Angle and Scale of the Nearest Copy. It is only exposing the Positions of the copy. Which makes it impossible to create an exact replacement of the copy for the things like chopping a tree and spawning a falling one after deleting the copy. (like the docs is suggesting it can be done) I understand you don’t need the angle or scale to create a falling log and spawning some effects, but while the data is there why not to expose it, so people can create perfect seemless transitions between instancedmesh and actual object.

I fixed all of these issues in my test project by editing the DefineScatterHelperClasses code and adding new expressions etc. but it is not convenient to use it that way in a long run in different projects and I also didn’t think of doing dropdown options like you done. Most importantly it will be good for everyone, because the issues I am surfacing right now eventually will come from other users when they want to use these features. Better fix it before it becomes a problem.

Bouh · November 7, 2026, 11:18am

As you know, this is an extension, and since you’ve already made the changes, I suggest you send it to us via the repo at GitHub - GDevelopApp/GDevelop-extensions: Repository of behaviors, actions, conditions and expressions to be used in GDevelop for creating games · GitHub

I’ll discuss this further internally with the team on Monday.

(If you already shared it, please link the url please)

Eldarduil · November 8, 2026, 6:10pm

Thank you for your suggestion and your care to bring this up to the team.

I did a PR

github.com/GDevelopApp/GDevelop-extensions

Terrain 3D Scattered Models update (#2356)

main ← Eldarduil:main

opened 05:35PM - 08 Nov 26 UTC

Eldarduil

+1184 -302

Sorry for the wall of text, but I felt like I need to tell everything. Thank you… for your understandings. ## Reasons: 1. it is impossible to scatter objects properly touching the terrain mesh. 2. it is not possible to use Z+ up models. 3. it is not possible to do proper object replacing with a copy, because lack of angle and scale expressions. ## Changes: ## **v0.3.0** Bouh did add 2 drop down properties that allows user to change which point of the 3d model to use to place copies and option for if the model is Y+ up or Z+ Up model. Can be seen in this forum post: https://forum.gdevelop.io/t/terrain-3d-scattered-models-does-not-use-object-origin/78811/1 Using the model origin solves the issues that asymmetric object's wrong trunk collision positions and floating model on slopes. and allowing to use Zup models. ## **v0.3.1 (here is my changes and additions)** ### **Height Property is changed to Scale Factor:** If a User wants to match the 3D model and Scattered models dimensions this makes it easier. Because in 3D model object Scale Factor = 100 means model's original size. You set the scale factor to 100 in both Scattered Models and in the 3D model and you are good to go. This helps for easy workflow. In the old version it feels odd that I need to feed the Height of the object to the system if I want matching sizes. There are no 3D systems in gdevelop uses height of the object as main dimension property as I can think of. Consistency across all gdevelop features is important. So with that The changes in the code uses the _getScaleFactor instead of Height calculations. Except matrices, raycast, fade shader etc. continue to read copy.height . so no harm done to the other systems in the code. ### **Two new Expression functions added:** NearestCopyAngle & NearestCopyScale are needed for exactly swaping the instancedmesh copy with the regular object. With these new expressions seemless replacement can be done. Previously it was very disappointing that you can place the object only at the copy position. when I first see the object that I create doesn't even matches the angle and size, it creates a very cheap game feeling and it is unacceptable while the code has all the data about the copy. anyway now we have access to that data. ### **One new extension action is added:** It is called ReplaceNearestCopyWithObject . it does the replacement actions automatic for the user. (if you see the examples events it is basically applying the copy's transform to the created new 3d model one by one. nothing fancy. just removes the manual labour for creating series of actions. It needs to be extension action, because Custom object functions cannot create scene objects. they can only create child objects of the custom object. I have done these changes with in-engine AI assistance. Since now it can read the extensions it is good for pin pointing the locations in the code and helping to understand structure of the system. Also I am familiar with these type of system because I have made Scatter On Surface community extension which is very similar. ### _**Something to note:**_ When you use the bbox bottom center for scattering the objects and when you want to swap it with 3d model. The 3D model origin point and object center should be chosen bottomcenterZ to have a seamless swapping. which is not ideal because now you gonna have problematic physics3D shape positions and calculations etc. I am not sure giving user a option to use object bottom center for scattering is wise choice. Not even giving it on default. it shouldn't be given at all. Because it causes problems than solving it. A terrain object is almost never flat, so there will be always floating copies if you use the bottom center. Even if you have a proper 3d model lets say a flat bottomed rock, you want to sink a little bit inside the terrain to avoid floating bottom. so in the modelling part of the object you sink the model a little bit lower than the origin point. But when you come to the engine, the engine suggest you to use bottom center on default and it completely pushes the object up again completely overrides your floating prevention in the modelling part which is accepted design principle in game development. So using bbox bottom center is awfully wrong. Every time people needs to fix that by switching to "use model origin" option. I can't think of any use case for bottom center scattering. even in top down game it will show the shadows offset from the object base for the objects that are at the slopes and has asymmetric shapes. Another thing is in-engine AI keeps telling store installed extension (terrain3d) is read-only. which AI can't edit unless you duplicate. User can Edit, but you get "hey update this extension or skip it" popup when you change something in the extension. ### **Future update suggestions:** It would be good to have an option to rotate the objects along the slope face normals. Like "Align Rotation" option in Blender's Scatter on surface modifier. Of course with that we need new rotation expressions for the copies. ## Example project [Terrain Scatter Fix.zip](https://github.com/user-attachments/files/34550066/Terrain.Scatter.Fix.zip) In the example; You can see both 3d models one is coming from the LeafyForest prefab (Common_Tree_1, Y+ up) the other one is from Quaternius assets that I gave it a custom name (Tree_Asym_Z_01, Z+ up). In both examples the seamless object swapping is perfect. Common_Tree_1 is dynamic Physics object. Tree_Asym_Z_01 is static physics object, giving examples of two different approach what can be done after replacing the object. Notice that Common_Tree_1 has 0 Z rotation in the object properties. that is important for the matching replacement. Gdevelop brings any 3D model with X: 90, Y: 0 , Z: 90 rotations to fix the Y up models to Z up orientation. that extra Z rotation is not accounted in the Scattered model data. so if it left z: 90 it will not match the angle of the copy. Which we shouldn't even think to fix or change things. This should be users responsibility to properly setup their 3D models. Gdevelop already messing up with the user by automaticly rotating the 3d models. The engine assumes every model is Y+ up while the 3d engine itself is Zup. that is another topic for another day :P ## AI usage - [+] I used an AI to generate some part of the code.

Bouh · November 9, 2026, 10:17pm

I did a few edits and fixes. I’ll let you take a look in case there is anything else, and I’ll merge it later today.

The fact is that I had to put the “size” field back in for backward compatibility; otherwise, people would have smaller objects on their existing terrain.
Please verify by checking your projects that have a “size” field defined; using the version I fixed should not change the dimensions of existing trees.
The “size” field is marked as deprecated, so it is hidden, and the “scalefactor” is used if it is filled in, as you requested.

Eldarduil · November 10, 2026, 1:50am

I saw your edits today and thank you for that. You are the king Bouh.

Now I test your latest version. After updating the extension, all the prefabs are ignoring the new “Scale factor of copy” property. Existing one and also the newly created prefabs. They are stuck to their previous height property.

Even if you create new Scattered Models object and choose any of the prefabs, the scale factor property change nothing. Only way to change their sizes is Min/Max size properties.

If you press “skip and create from scratch” scale factor property is working.

But getting copy angle and scale works fine for the old and new prefabs.

Bouh · November 10, 2026, 9:32am

It’s been adjusted. I also took the opportunity to add a breaking change notice to the extension update to warn users about the change to the “model anchor”, which now defaults to “model origin”.

There is no way to preserve the previous behavior through a default value (because there is none), so this will inevitably change the position of some models. The breaking change notice explains what needs to be edited to restore the original positioning in their project.

Eldarduil · November 10, 2026, 1:46pm

Thank you for your hard work. I really appreciate your effort to make Gdevelop features better. Thanks again.

Bouh · November 10, 2026, 1:59pm

Thanks for the help on this update.
The extension has been merged, with this changelog to be displayed in the next version of GDevelop:

Terrain 3D Scattered Models update (#2356)

Allow choosing the up axis of the 3D model (Y or Z).
By default, the origin of the 3D model is now put on the ground, instead of the center of the model base.
Allow resizing the 3D model with a scale factor, instead of a fixed height in pixels.
Added two expressions to get the angle and the scale of the nearest scattered copy.
Added an action to create an object in place of the nearest scattered copy (the object is created on the layer of the scattered models object).