Factory spawning large numbers of tree meshes

#1

I have three factories each spawning a different type of tree:
image

Each tree is a go with a mesh and nothing else.
The meshes are around 1K in polygons (tris).
When I use this method in my ‘forest’ builder using a simple perlin noise generator, I generate around 1600 trees. And this generates some possible performance issues.

The two items that concern me:

  1. This appears to be getting set every frame? Even for static objects? Im going to have a look at the source for this, but it seems strange with a large pool of static meshes from factories.
  2. The vertex count seems wildly out (by about 100x)? Unless it is because of the PBR shader which uses a number of texture inputs (this doesnt seem likely).

I havent really spent much time with this yet, so if Im doing something stupidly wrong please let me know - its very likely.

I also noticed, there doesnt seem to be any object clipping happening? Is that correct?
I kind of like that, because that allows me to implement a way to manage per channel vision objects.

Oh. I’ll try to make a simple example to test. To ensure the other code I have isnt the cause.

0 Likes

#2

Yes, the "Issue-5167 - Fixed : Mesh components can share vertex buffers" is in the 1.2.181 Beta and is scheduled for release today.

6 Likes

#3

Correct. We do no culling or anything like that. Issue: https://github.com/defold/defold/issues/3406

0 Likes

#4

Oh. Thanks. I didnt check the issues. Sorry about that. Very awesome timing :slight_smile:
The clipping thing is actually nice :slight_smile: … assuming I can enable/disable go’s ok :slight_smile:
Thanks @Mathias_Westerdahl and @britzl for the crazy fast responses. Awesome.

1 Like

#5

What we’re most likely to add first, is frustum culling, and later on occluder culling.
At the same time, we’ll also add a C++ api to the culling mechanisms too, to allow for game specific culling.
Currently, we don’t have any bounding volumes around our objects at all, so that’s a first step that needs to be solved.

Secondly, we need to design the actual feature, i.e. how should it work when an object gets culled. E.g. should it stop updating or not? How often should it update etc.
And, what about rendering? E.g. rendering objects in a mirror (e.g. water surface) that are next to the camera, but outside the frustum.

Most likely we want to make some Lua callback for the objects that got culled.
Anyways, we haven’t started looking into it yet.

6 Likes

#6

Not a proper solution of course but I was using this for at least enable/disable large amount of go’s

2 Likes

#7

Thanks, thats pretty cool. Obviously suited to 2D spaces - could potentially convert, but I have octrees and similar in lua I have written before :slight_smile: Will probably use iso-surfaces for perf… much faster for frustum culls. Dunno… will have to see what suits best. I suspect will end up a native-extension again. Have made a few of those in the last week :wink:

1 Like

#8

What is your opinion on the workflow for creating extensions? And your thoughts on the SDK? What are we missing? What can we improve to make the process better for extension creators?

1 Like

#9

From an initial use case perspective (early days) I like the native extension setup. I work a great deal with C libs and C wrappers in my work and in the past, so I find it very convenient and powerful.

I do wonder if theres a nice way to make it ffi friendly :slight_smile: … I know html is pretty much impossible for that, but it makes me think there might be a nice way under the hood to map C libs like like ffi does - or even using the powerful ffi.cdef system to do so. Im thinking this as I go, so stay with me :slight_smile:

Your current api is traditional registration setup via C/C++. This is fine and how normal lua does it, so its probably quite familiar to most people anyway. However if you could use the ffi.cdef (or similar) to define the wrapping calls then it would make things very clean when building external interfaces. The reasons I like this:

  • The interface is then defined where you use it (in lua) and thus needs minimal documentation.
  • An extension could simply provide static cdecl definitions and thus allow a wider array of calling conventions (allowed by C)
  • It should be nicer to manage on the Java/integration side because you end up with some simple C handlers rather than problematic method conversions.
  • A wider array of libs would almost be directly accessible.

The big drawbacks to this:

  • Difficult to control and manage the environment and thus track bugs and issues (this is quite a large prob).
  • Potentially nefarious code could get in - although with open source, this is more difficult in reality.
  • Not sure how package management and extension management would occur - might be more problematic.

As it stands at the moment. I like the way it works :slight_smile: … but thats just me. I like systems that utilise tools and frameworks to allow the developer to achieve their goals - and more importantly, extensible enough that you can find ways around problems. So far… Defold nails it on this aspect.

One thing I would probably be critical of, is the editor. I think there are elements to it that are somewhat dated and probably need some love (I havent checked issues so they may be already underway). For me, these are:

  • Undo/Redo is extremely flakey. This might be a Linux Debian GTK thing. Not sure.
  • General “feel” is a little stilted - hrm, this is hard to describe, but it isnt ‘snappy’ where it should be. Generally key and mouse input in an editor should be number 1, everything else gets a “waiting” bar… or something like that if its taking time (with cancel).
  • There probably needs to be a separation between 3D and 2D editing for scenes (collections). I think reference to Unity3D’s setup here is a good idea, although, thats a little messy.
  • I dont wanna sound like a language fan so and so… but I think Java may not be ideal for 2D/3D editing systems. Our sims used Java heavily for control panels and track editing, and they get big and cumbersome quickly. Which sort of goes against the “light and extensible” idea of the Defold system - I get java needs to be used, and it is key to things like cross platform editor visuals, but I think a longer term road map may want to look at systems like html/electron or even utilizing your own GUI builder and make the editor in Defold :slight_smile: … yeah… sorry… probably too far…

Anyway… dont change too much just because of an old coder… drive your own path! … I’ll stick around.

4 Likes

#10

Erg. Sorry about all that brain dump.

0 Likes

#11

No need to apologise. Thank you so much for sharing your thoughts. Much appreaciated!

0 Likes

#12

Just an update. The new release today. Damn… talk about a big improvement. The first issue in the above post… gone :slight_smile:


Thanks guys… utterly brilliant.

3 Likes