3D video (underwear - maybe not safe for work)

[ozRocker]

This is just another experiment with animation and making it work on mobile devices.  If anyone has any issues viewing it, please tell me http://www.punkoffice.com/barb/

 

I can only use 25 bones maximum on iPhone which is a shame because I can't rig the fingers separately.  Any more bones and I get the "Too many uniforms" error.  I'm not sure if there's any way around this.  I even tried to half the polygon count and it didn't help.  I guess I have to hope for RAM increases with the upcoming phones.

 

[GameMonetize]

For iPhones you can try to turn software skinning on with mesh.computeBonesUsingShaders = false

[ozRocker]

For iPhones you can try to turn software skinning on with mesh.computeBonesUsingShaders = false

Ok cool, I'll give that a go next time and see if it gives me a few more bones.

 

I've noticed that the .FBX file is 3.15MB but the .BABYLON file is 6.95MB  and its not getting compressed any further from the web server.  Is this cos the .FBX file is a binary file?  If I could get the .BABYLON file the same size as the .FBX file that'd be awesome!

[GameMonetize]

It will be far better. Just turn gzip on on your server:)

[JCPalmer]

First off:  A warning about underwear??  Wow, I thought I saw a Mocap for a 'kick line' (it was in french).  Once my QueuedInterpolation system got closer to done, was going to do a test scene of nude young women (wt genitalia), maybe with breast shapekeys for bouncing .  Dude, you are making me look bad.

 

In addition to transmission compression, there may be other things.  I am going to assume you are coming from Unity.  I remember you expressed an interest improving its exporter.  Here is one of the first things I did to the Blender exporter.  It was generating float strings, always with 4 decimals.  I made a function which stripped trailing 0's.  If there was a '.' at the end, then get rid of it too.  I cannot remember how much reduction I got, but think it was about 10%.  That 700kb in your case.

 

Here it is in Python:

def format_f(num):    s = MAX_FLOAT_PRECISION % num # rounds to N decimal places while changing to string    s = s.rstrip('0') # ignore trailing zeroes    s = s.rstrip('.') # ignore trailing .    return '0' if s == '-0' else s

I also just did it again in my mocap class.  It has a toTypescript(), so you do not have to distribute 120 fps mocap files & parse them in the game.

Here is the typescript version:

/* get as compact a number as much as possible with 4 decimals of precision */private _fmt(vals : number[]) : string{    var ret = "";    for (var i = 0; i < vals.length; i++){        var val = vals[i].toFixed(4).toString();        while (val.charAt(val.length - 1) === '0'){            val = val.substr(0, val.length - 1);        }                    if (val.charAt(val.length - 1) === '.'){            val = val.substr(0, val.length - 1);        }        ret += val;        if (i + 1 < vals.length) ret += ",";    }                return ret;}

Maybe just the project that directly helps you, but not too difficult for getting started.

[ozRocker]

Actually, I used only Blender for this.  The Unity3D Exporter doesn't export armature and animation (as far as I'm aware).

 

I am running GZIP on the web server.  It compresses other files but it doesn't compress the .BABYLON file.  Is there something else I need to do to compress it? Or am I reading the developer tools incorrectly?

 

[GameMonetize]

It depends on your server but you should check headers returned to see if the .babylon is really gzipped by the server.

 

For instance the Espilit scene on babylon.js is 27Mo but only 3Mo when sent to the client

[JCPalmer]

Ah, blender, my bad.  Good news is the next version of the Blender exporter, late Demember, is going to massively reduce the export size of .blends with armatures.  The current version, writes out a position for every vertex when there is a skeleton, whether another triangle shares it or not. 

 

This affects size of: positions, normals,  uvs, uvs2, colors, skeletonWeights, skeletonIndices, & shapekeys. Once loaded in BJS, this reduces memory requirements on both cpu & gpu.  Shapekey morphing cpu & cpu skinning are also proportionally reduced.  I do not know if vertex optimization does anything for gpu performance.

 

As an example, take a fully decked out high poly MakeHuman with teeth and tongue (without any Limited Dissolve editing).  When merged all together, this is what the current exporter will log:

WARNING: Due to multi-materials & this meshes size, 32bit indices must be used.  This may not run on all hardware.WARNING: Maximum # of influencers exceeded for 20873 vertices, extras ignorednum positions      :  140280num normals        :  140280num uvs            :  280560num uvs2           :  0num colors         :  0num indices        :  140280num skeletonWeights:  561120num skeletonIndices:  561120

The next version export of the same mesh logs:

num positions      :  29433num normals        :  29433num uvs            :  58866num uvs2           :  0num colors         :  0num indices        :  140280Skeleton stats:  	Total Influencers:  60377	Avg # of influencers per vertex:  2.0513	Highest # of influencers observed:  7	exported as 7 influencers	Compute bones using shaders:  true	num skeletonWeights:  117732	num skeletonIndices:  117732

An optimization, using Limited Dissolves, especially of the teeth, greatly reduces these numbers as well.

[ozRocker]

Thanks for the tips everyone!  It turns out my .babylon files were not being compressed.  I thought everything gets compressed on the web server, didn't realise it was only happening for only some file types.  I added the .babylon mime type then set compression for it and now its getting compressed. YAY!! 

 

 

Looking forward to even smaller files from the new Blender exporter

 

Edit: For those that want to know what I did

 

I edited the apache2.conf file so it applies globally to all my sites

I added these lines:

# Mime typesAddType application/json .babylon# CompressionAddOutputFilterByType DEFLATE application/json

[GameMonetize]

See? Lower size than your fbx

[ozRocker]

I noticed with GZIP compression enabled my callback function changed.  Before I used evt.loaded and evt.total to create a progress bar, but with GZIP on evt.total is always zero so I can no longer get a percentage from that variable.  Its not the end of the world because I know the actual size of the .babylon file, but it would be nice if I didn't have to hardcode it in

[Vousk-prod.]

That's unfortunatly impossible for BJS to determine the file size when gzipped by server.

[ozRocker]

For iPhones you can try to turn software skinning on with mesh.computeBonesUsingShaders = false

 

I just tried this and I still get the same errors on iPhone with 42 bones

[JCPalmer]

On another thread, gryff managed to trip the auto downgrade of skinning and logging in 2.3.  I was not able to test this, so I was glad that it happened.  I am wondering, since this is most likely to occur on a mobile device, whether these logs should be turned into window.alerts.  Getting a browser log on phones is not always possible.  Even if actual customers are actually seeing these, it may be very helpful supporting them.

 

Sorry Oz, I cannot be helpful.  Finger manipulation using bones is going to be tough for mobile.  Someday, there may be an alternative, if you can built hand shape keys.  Requires Blender, Tower of Babel, & future QueuedInterpolation extension though.  When you say you get the 'too many uniforms' error, how do you know?  Prior to 2.3, downgrading was completely silent, I think.  I only have an iPad, but I never saw how iOS safari could show the console.

[GameMonetize]

Are you sure you use the computeBonesUsingShaders on the right mesh? There shouldn't be a problem for iPhone then. can you share your experiment somewhere (with reference to babylon.max.js for debugging purpose)

[ozRocker]

ok, I've got it set up on the playground here http://www.babylonjs-playground.com/#1I1DDF#0

 

I've set computeBonesUsingShaders to true in that demo, but for some reason when I set it to false it won't even show up on the playground

[JCPalmer]

I can run it.  With or without forced cpu skinning, the fingers look wrong (a little fast, but I can tell).  I am running on a gtx960, so I do not get a console log auto downgrade message when I just default to gpu.

 

I think the problem is different from what you think.  I opened up the debug layer.  It reports you have "0" meshes, "0" vertices.  You broke it.  what happens when you run this on 2.2?

[ozRocker]

I've noticed I'm getting different results for Babylon 2.2 and Babylon 2.1.  I've put up a webpage with this animation.  Just ignore the way the hands look.  That's an inaccuracy with the rigging.  I'm happy as long as they have bones and are not straight hands for this experiment.

 

preview.punkoffice.com/hands/ - (default) Babylon.js version 2.2, compute with shaders = TRUE

preview.punkoffice.com/hands/?version=2.1&shaders=false - Babylon.js version 2.1, compute with shaders = FALSE

preview.punkoffice.com/hands/?version=2.2&shaders=false - Babylon.js version 2.2, compute with shaders = FALSE

preview.punkoffice.com/hands/?version=2.1&shaders=true - Babylon.js version 2.1, compute with shaders = TRUE

preview.punkoffice.com/hands/?version=2.2&shaders=true - Babylon.js version 2.2, compute with shaders = TRUE

 

[GameMonetize]

Warning: compute with shaders was introduced with bjs 2.2

[ozRocker]

ok, I'll stick with 2.2 and above for this experiment.  Does anyone know why my mesh doesn't show when I disable computing with shaders? http://preview.punkoffice.com/hands/?version=2.2&shaders=false and http://www.babylonjs-playground.com/#1I1DDF#0

 

I haven't done anything funny to the .babylon file.  Its straight from a Blender export and it runs as expected when I have compute with shaders set to true.  

[GameMonetize]

Just add this:

mesh.material.checkReadyOnlyOnce = false;

 

@JCP: we should definitely remove this flag by default

[ozRocker]

I got it working, YAY! I disabled "checkReadyOnlyOnce" so now my mesh shows up.  But I also discovered my code would stop with an error at "executeWhenReady".  I had my "computeUsingShaders" code in there so it never got executed. I took that code out of the "executeWhenReady" body and put it in "SceneLoader.Load".  I didn't realise I could access the scene contents before "executeWhenReady" but turns out I can.

 

The frame rate is noticeably slower but that's expected.  Maybe I can reduce quality to speed it up.

[GameMonetize]

Excellent!

[JCPalmer]

Yep, already done.  See the checkbox on the picture on the Material namespace topic.  Responding there right after here.

 

CheckOnlyOnce in the vast majority of cases can be enabled, unfortunately when it cannot, it can fail in unknown ways.

 

@oz:  Keep your old Blender log file for this, and get ready in the next few days to re-export.  Your file size is going to drop off a cliff.

[JCPalmer]

The fact there is now an auto fallback to computeBonesUsingShaders = false  (which I very much like), it would seem you can never set checkOnlyOnce unless the fallback code also marks the meshes material dirty like:

public reduce(currentDefines: string): string {    var currentFallbacks = this._defines[this._currentRank];    for (var index = 0; index < currentFallbacks.length; index++) {        currentDefines = currentDefines.replace("#define " + currentFallbacks[index], "");    }    if (this._mesh && this._currentRank === this._meshRank){        this._mesh.material.markDirty();        this._mesh.computeBonesUsingShaders = false;        currentDefines = currentDefines.replace("#define NUM_BONE_INFLUENCERS " + this._mesh.numBoneInfluencers, "#define NUM_BONE_INFLUENCERS 0");        Tools.Log("Falling back to CPU skinning for " + this._mesh.name);    }    this._currentRank++;    return currentDefines;}