Obj loader loads in blender but not in Babylon

[chicagobob123]

I was able to load a container I had in OBJ format but the texture looks all wrong. 2 out of 6 sides are OK.  I load the same model into Blender and everything is OK. Is there more I can do? 

Not much code in here.

Also if you are reading this how do I NOT load it directly into the scene?

I want to attach it to a particle instead. 

 

   var loader=new BABYLON.AssetsManager(scene);

       var CargoContainer=loader.addMeshTask("C1","","/mb/CargoContainer/","Cargo_container_01.txt");

       loader.onFinish=function()
        {
         // animation
         var dir = BABYLON.Vector3.Zero();
         var pos = BABYLON.Vector3.Zero();
         scene.registerBeforeRender(function() {   
             camera.position.scaleToRef(2, pos);
             dir.copyFrom(pos);
             dir.scaleInPlace(-1);
             dirLight.position = pos;
             dirLight.direction = dir;
              });

           // run the render loop
           engine.runRenderLoop(function() {
            scene.render();
           });
        };

     loader.load();

[dbawel]

@chicagobob123 - Have you attempted to export as a .babylon file with a native Blender primitive mesh with the same properties applied such as materials and textures as a control test mesh? This should provide you with the answers you're looking for in comparing the results in BJS. Unless however, the .OBJ mesh is a native pimitive Blender mesh. If you post the Blender file for review, I'm confident you'll receive an answer from the community in short time, if my above suggestion doesn't apply.

From my own personal experience, it is the process of unwrapping UVs to produce the same result you see in Blender. Also, it was essential to unwrap the UV texture coordinates using the Cycles Renderer in the past. I don't know if this is still the case, however it certainly was the case one year ago.

DB

[chicagobob123]

I am going to try that now. 

Was just looking for the .py file in the download folder. 

[chicagobob123]

It loads correctly and I like the lighting it seems to render correctly. 

I still dont get this.Using the addMeshTask seems to auto load to the scene. How do I not load it to the scene but instead attach a mesh to a particle? 

Can this even be done? 

(I know such a newbie sorry)

[dbawel]

@chicagobob123 - Here is a Playground scene which I believe @Deltakosh posted - but If I'm mistaken, please forgive me for not noting correctly. This scene attaches a BJS box object to a particle system, but you can use this to attach practically any mesh you like. But keep in mind optimization, as you'll be running prettu hot on mobile devices such as the S6 and S7 smartphones - if you plan on supporting mobile devices.

http://www.babylonjs-playground.com/#16SA9C#9

DB

[gryff]

Quote

Also, it was essential to unwrap the UV texture coordinates using the Cycles Renderer in the past. I don't know if this is still the case, however it certainly was the case one year ago.

@dbawel. I've been using Blender for over 4 years for Unity, Second Life, and BJS. Never had to do that - always worked fine in the Blender Renderer.

cheers, gryff

[dbawel]

@gryff - It may not be an issue anymore, but at some point, I definately ran into compatability issues in not using the Cycles Renderer to unwrap UVs. However, I personally don't have enough specific info to warrent why. However, I discovered greater compatabilty at the time - but this was quite a while ago. So just trying to help troubleshoot from personal experience.

Perhaps @JCPalmer might chime in to help understand why there was some compatability issues prior, but obviously not for everyone. So JC, any thoughts?

DB

[JCPalmer]

I have never imported an .obj (whatever that is) into Blender, but on the assumption that it is just a mesh after that, it should be able to be un-wrapped with either.  Think the issue might be "shouldn't the importer un-wrap it anyway??".  Is there not UV in the .obj file that says how the texture maps?  Might the importer also be picking which render to use.

As an aside, the facilities inside the .babylon exporter for cycles are to just bake it into a texture.  This has the side effect of creating a separate texture for every mesh with no sharing.  If something can be done with the Blender render, I would recommend using it over Cycles.  The ability to bake for Cycles is just so complex materials can still be used / and continue to be edited.

[dbawel]

@JCPalmer -

Your advice on using the Blender Renderer is duly noted. FYI - the .OBJ format is an object (mesh) format which developed out of the Wavefront software applications prior to their aquisition by Alias over 15 years ago. At the time, it was developed with the expectation to use as one of the first universal mesh formats for use as a conversion standard to import/export mesh objects between the different modelling and proceedural applications at the time in the mid 90s. Wavfront released this with only mesh and vertex information, and not material or other properties of the mesh included in the .OBJ format - until Wavefront opened up all rights to this and other cevelopers began to introduce additional properties to the .OBJ file format in roughly 1999.

But there were initially incompatabilities in using this file format between different software applications, until Alias and Autodesk set the standards for the .OBJ file format for the entertainment industry in 2001. Before this, and certainly since then, it has been a widely supported file format with substancial support of the format and it's standards in practically every modelling and rendering application ever since. So this is the history of the .OBJ file format strictly from memory, but the info provided here is factual. I don't believe that Wavefront claims any ownership of the ,OBJ file format any longer, and it is now the most widely supported file format for mesh objects in use today.

But always be aware that even though Alias set standards and Autodesk has continued support of these, you'll often find many properties unsupported depending on the software you are using - especially legacy issues with it's use in products and applications prior to 2001.

Wow, I'm the old dude now.

DB

[JCPalmer]

Most of the people writing the code or answering questions for BJS are the "old dudes" or approaching.  As a 2nd generation programmer with 30+ years professional experience (40 if you count high school), it just does not matter how little I know the subject matter any more.  A younger person tries to avoid saying they do not know something too often, especially in a work environment.  I just do not care anymore. 

Causing people to under estimate me has it perks.

[chicagobob123]

>>Most of the people writing the code or answering questions for BJS are the "old dudes" or approaching. Now isn't that interesting.<<

You would think it would be younger guys considering this is pretty cutting edge. But you can count me in the Older Gentlemens club. 

About 30+ years into this now.