3.5 Million Triangle part (A theoretical discussion)

[noonespecial]

So here is an experiment I did, partly to see if KSP supported it and mostly just to see if it were fracking possible.

Step One:  The control model.  A 3.5 Million Triangle monstrosity that took me all of 5 minutes to model in Blender.

As can be expected, the result was a complete disaster.  Firstly, the model exported out of blender at just over 150mb.  It took me about 4 attempts (with various export tweaks) to even get Unity to import the model without crashing.  It took several other attempts to even get PartTools to export it without crashing.  And, as could be expected, it essentially took a base bones unmodded KSP to load the model and even then, it didn't like it.  Loading it in the VAB dropped the FPS to 1 and essentially froze KSP.  End result:  Absolute failure.  As expected.

Step Two:  Experimental model using Duplicate Faces.

Start by recreating a section of the previous monstrosity.

Then create a cube, subdivided into equal squares roughly the same dimensions of the honeycomb section.  Then, parent the honeycomb to the cube, select the cube and active the duplicate faces option.

Which results in a total triangle count of just under 6 thousand while having roughly the same display as the first honeycomb cube.

I could have done some neater work to make each section line up better, but this was just experiment, so frack it.  Anyway.  The blend file saved out to 715k (as opposed to the 150m file of the original).  Unity import and displayed the part without a hiccup and even PartTools exported it without trouble.  Although, I did notice that the resulting mu file was about 400mb in size.

Then, the final test.  I load up KSP and....

It worked!  The load screen hiccuped when it hit the file, but only delayed for a few seconds.  Load it up in the VAB was okay (FPS took a pretty big hit, from 60 to 45 FPS).  Stuck it on a rocket and launched it into orbit.  And..

I'm going to continue to experiment with this with more practical applications, but I'm wondering if anyone else has ever attempted similar experiments and what were your levels of success(es)?

[NecroBones]

That last one only had around 6,000 tris? That doesn't sound bad at all. Are you sure that's all it had?

 

I can't say I'm surprised at the results of the 3.5 million model.

 

[noonespecial]

I wasn't surprised by the results of the 3.5 million either.

The final mesh had 5,980 triangles, between the honeycomb segment (3,520) and the parent cube (2,460).  The game engine then creates instances of the honeycomb and spreads it across each face of the cube.  In the original, the computer/game engine has to calculate and render each vertex.  In the second, it only calculates and renders the much smaller honeycomb segment, then copies it onto the rest of the parent cube.  It is more expensive to render in realtime than just 6,000 tris, but significantly less than 3.5 million

Although, I'm more interested in seeing it applied to something like this

There are 70 identical 12 sided bars supporting the structure of this lander.  I had to skip a lot of details due to already running pretty high on polys after just being the frame.  It would free up nearly 2,000 triangles worth of details by "instancing" out all the duplicate bars instead of creating unique mesh duplicates.  I'd be interested to see if there is a performance difference between those two models.

[landeTLS]

Too sleepy to respond properly but i have gotten objects of > 1m tris to load in ksp in the past. The thread about it is somewhere in the forums. They took a while to load in the scene but once loaded the fps drop was minimal. The only performance effecting things i did that i can think of was making sure all the meshes had good precalculated normals, uvs and a single material instance with a blank texture. The fact that you are using duplifaces inside blender really should not be effecting the exported results(as all that does is instance the meshes and combine them in the backend). If you dont believe me then try exporting the object as obj/fbx and re import into blender/other sw. Eg. Geometry is geometry. So my first thought is that there might be something else going on. 

[CaptainKipard]

So how do you get to control what's instanced?

[noonespecial]

9 hours ago, CaptainKipard said:

So how do you get to control what's instanced?

With duplication faces in Blender, you need two objects.  It is easier to work with if both objects share the same origin.

In this case, I want to use the plane to duplicate Suzanne, so I'll parent Suzanne to the plane.

Then, lets go into Edit mode of the Plane and create a few more faces.  Where you put the additional faces will be where Suzanne will be instanced to.

Under the Object tab in properties, under the Duplication section, select faces. And... presto

You can also use the planes to control orientation of the instance:

   

When it is rendered, or displayed by a game engine, the faces of the plane are not displayed, only the parented object.  You can also parent multiple objects.

[noonespecial]

A better example of how to control it and use in KSP:

So let's the ole Orion here.

Let's say I want to put a row of bolts going down the side.  So let's create a plane and a bolt object.  Remember, Two different objects sharing the same origin.

Then I'll go into Edit mode of the plane and create another face going down the side of the Orion.

Parent the bolt to the plane and duplication...

So now you have a nut on the side of the Orion.  Meh, not very useful.  But, since Duplication Faces relies on the face count of the object.  Let's Loop Cut that face.  19 cuts sounds like a good number.

 

Edited December 22, 2015 by noonespecial

[Hary R]

Wow that's a usefull trick. 

[NecroBones]

OK that's pretty cool. That could be a big time saver.

[CaptainKipard]

So this is only useful for geometry that would otherwise share UV space.

I take it that it's the parent that needs to be imported into Unity?

[noonespecial]

3 hours ago, CaptainKipard said:

So this is only useful for geometry that would otherwise share UV space.

I take it that it's the parent that needs to be imported into Unity?

Yup.  All the duplicated objects are copies of the original asset, sharing geometry, uv, etc.

You would have to export the the parent and all child objects.  Otherwise, the parent wouldn't know what to instance in the game engine.

[NecroBones]

By the looks of it, this looks like a trick that's internal to Blender, and upon exporting to Unity it probably turns back into raw, complete mesh objects. I doubt Unity handles blender duplication natively. I could be wrong though.

 

[noonespecial]

53 minutes ago, NecroBones said:

By the looks of it, this looks like a trick that's internal to Blender, and upon exporting to Unity it probably turns back into raw, complete mesh objects. I doubt Unity handles blender duplication natively. I could be wrong though.

 

As far as Unity handling it natively.  I do believe you're right.  I habitually export to FBX instead of importing the blend file directly into Unity, so I didn't notice initially.  Unity gave me a "cannot convert to FBX error".  However, using the cube example from above, exporting the all unique assets 3.5 trillion poly model resulting in a 140m file that Unity chocked on, even in FBX format.  The duplifaces model exported out to less than 1mb and Unity imported it without issue. 

If I understand it correctly (not guaranteeing that I do ), Unity considers the duplifaces are instances of a Prefab, with the original component being the Prefab within the model.  Basically, the parent object is just telling Unity where to place the Prefabs.

My main concern, however, isn't what is happening within Unity, but what is happening within KSP.  Unity handled the file without trouble, displayed it correctly, and ran without lag.  Once exported through PartTools, the file ballooned to just over 400m.

So is it beneficial to use?  I think in some cases, it could be a useful time saver, such as the bolts on the Orion above (or if you want to make an insanely highpoly model that Unity chokes on). 

[Jovzin]

wau great thx for info. we have something simmilar in Maya called duplicate special. 

[landeTLS]

On 23.12.2015 at 6:01 AM, NecroBones said:

By the looks of it, this looks like a trick that's internal to Blender, and upon exporting to Unity it probably turns back into raw, complete mesh objects. I doubt Unity handles blender duplication natively. I could be wrong though.

 

Yes you are right. I detailed this earlier in the thread, even tho appearently nobody appeared to take notice of it( willful ignorance? )

To go deeper into the reason for this the duplifaces(also dupliverts duplispline etc) inside blender impliments a common method of "batching" geometry operations at rendertime for meshes that share the same geometry. It is more effective than regular instancing via arrays and instanced clones partly because the clone meshes are "forced" into a non editable state and the renderer can therefore directly reference the original mesh applying it to the proxy object (in blender this is the child object). Saving both memory and rendertime in the process. 

In 3dsmax the native implimentation is called scatter and multiscatter. The vray and mentalray renderers also has their own implimentation called vrayproxy and mrproxy.

The first thing to note is that these methods are excellent for renderers and applications where each frame is predetermined and calculated in a non-realtime fashion.

But for gameengines this is not the case. Unity3d offers an implimentation of realtime "geometry" batching called static/dynamic batching Read about it here 

which(i would think) is implimented by the static objects(ksc buildings etc.) . But this process do not work well for objects that are moving around. As well as it only batches drawcalls. It does not try to proxify mesh geometry(if this is even possible in a realtime application) but instead tries to build a buffer for said geometry to speed up drawing operations(which is kind of similar i guess). for static batching this needs to be explicitly set up inside unity and does not carry over from external applications. As for dynamic batching it currently only applies to meshes with very low vertex counts.

The second thing to note is one of abstraction. When you "import" a .blend file directly into unity. Unity automatically exports your mesh(es) via blenders built in fbx exporter. All this happens without giving any clue to the asset developer (the modder) that it is. This means you can easily make the error of assuming that everything in the .blend scene gets carried over into unity. But you would be wrong.

As everything gets standardized into the fbx format. Ie. all blender-native features get tossed and the mesh converted to a simple mesh. The only things that are kept are standardized fbx features. Things like channels. Uvs. Mesh Skinning. Animation clips and what have you. This is also why your .blend file can be tiny but the exported .mu file is gigantic. Also, As ksp runs on the unity game engine all the geometry drawing operations are unity native even if ksp uses a custom model asset format (.mu)

Tl;dr: as i said before geometry == geometry (aka you cant win with poly/vertcounts, the best you can ever do is break even*)

*obvious reference to the law of thermodynamics is obvious

 

Edit: added some smileys where appropriate...as that always makes things seem less ranty

Edit2: reread the last comment by noonespecial. It appears you realized most of these points on your own. Good job. The point you make about the prefabs is very close. That they are direct references of eachother in unity.that Is probably the main reason for the speedup. Since they share a common prefab reference they also share material instance and therefore material based drawcalls. Which is a major contributor to fps performance. This can be compared (and also achieved) via arrays(if blender exports them as instances) or regular fully instanced clones(mat and mesh data)(not sure what those are called in blender).

Or (perhaps more interestingly) it can be compared to grabbing a part in the vab and putting a bunch of it on a ship (as all those parts, including the first one, are concidered references to the same model prefab in unity). This is the same thing that is happening but inside the model hirearchy of that one prefab.

I must admit tho that i did cringe a bit about that usage of geometry(especcially that level of geometry) on single screwheads for a realtime application model. Please dont do that

Disclaimer. There are people on this forum much more informed than me about gameengine related matters. So i may myself be off on some info

Edited December 26, 2015 by landeTLS

[noonespecial]

@landeTLS

Thanks for the info!  Sorry, I didn't mean to give the impression that I ignored your initial post.  You said you were too sleepy to respond properly, so I was expecting you to come back and respond more fully.  So I was waiting until that to respond.  

Now that I think about it, I would cringe as well with that usage of geometry if someone were attempting to put that directly in KSP.  I would assume that a person who knew enough about Blender to pull off the duplication would also know enough to use them to bake normal maps to apply to a lower poly model

And again, thanks for the information.  Very enlightening.

[NecroBones]

On 12/28/2015 at 10:01 AM, noonespecial said:

@landeTLS

Thanks for the info!  Sorry, I didn't mean to give the impression that I ignored your initial post. 

 

Same deal here. I saw it, understood it, and then was basically trying to say the same thing. Apologies if it looked like I was ignoring it.

 

[landeTLS]

No problem guys. I was half joking about it. 

[riocrokite]

Interesting discussion So if I understand it correctly - to sum it up - those duplication techniques are not the way to go when it comes to optimizing performance of hi-poly parts for KSP?

[noonespecial]

13 hours ago, riocrokite said:

Interesting discussion So if I understand it correctly - to sum it up - those duplication techniques are not the way to go when it comes to optimizing performance of hi-poly parts for KSP?

At best, you could use duplication for high poly modeling on your models for baking out AO/Normal maps, which would improve the overall quality of your in game models.

This was simply experimentation to see what could be done and how in KSP.  While one could use these techniques to get a working high poly model in KSP, I wouldn't recommend it.

Edited January 3, 2016 by noonespecial