Importing Blender via Ogre SUCCESS, direct to JME FAIL. (13 posts)

Topic tags: Blender, import, Ogre
  • Profile picture of peterz peterz7p said 2 months, 4 weeks ago:

    Hi all,
    I compared exporting an object from Blender to JME using an Ogre .mesh.xml, against using the direct import functionality in JME SDK 3.0 beta. The results are below:

    The left hand image is pretty much identical to that in Blender – that’s from the Ogre mesh. On the right is the direct import to JME (I right clicked the .blend and imported it to a .j30). This is clearly very corrupted.

    Note that to generate the 3D texture, I exported a UV normal map and diffuse map from Blender, combined them into a JME Material, and applied the same material in both examples.

    The direct .blend import would be much quicker, so if there’s any way to fix it that would be great!

    #
  • Profile picture of mcbeth mcbeth19p said 2 months, 4 weeks ago:

    um if I were to make a guess I’d say it the subsurb(spelling) modifier you dont “seem” to apply before import

    #
  • Profile picture of peterz peterz7p said 2 months, 4 weeks ago:

    I agree that it looks like it’s subsurf related, but it’s the exported one that DOES work and the .blend direct import that doesn’t…

    #
  • Profile picture of normen normen1290p said 2 months, 4 weeks ago:

    Nobody said that the blender importer is production ready yet, actually we said the opposite multiple times. You would help us more if you a) actually make sure what gets transferred and what not and then b) provide test cases and test files for @Kaelthas to improve the importer.

    #
  • Profile picture of peterz peterz7p said 2 months, 4 weeks ago:

    Normen – My main reason for reporting this was to help improve the software. I will wrap it up in a test case and send it to the person you mention.

    Peter.

    #
  • Profile picture of mcbeth mcbeth19p said 2 months, 4 weeks ago:

    @peterz said:
    I agree that it looks like it’s subsurf related, but it’s the exported one that DOES work and the .blend direct import that doesn’t…

    doesn’t the ogre exporter apply modifiers on export? my point is maybe the subsurf is not “handled” properly if at all by the blend importer………you need only look at the pictures to figure that out

    #
  • Profile picture of peterz peterz7p said 2 months, 4 weeks ago:

    Thanks Mcbeth, yes I think you’re right – I will make a proper test case in the morning (GMT) to confirm. If it is the un-applied modifier as you suspect, then maybe it will be worth adding a note to the documentation.

    All the best,
    Peter.

    #
  • Profile picture of peterz peterz7p said 2 months, 4 weeks ago:

    Just to conclude (I’ve offered a test case to @Kaelthas), the problem is with the subsurf modifier – however, applying it before exporting from Blender – so the modifications are applied to the geometry and there’s no need for a modifier any more – surprisingly doesn’t resolve the problem.

    #
  • Profile picture of peterz peterz7p said 2 months, 4 weeks ago:

    Correction – having done a more thorough analysis, it’s not the subsurf modifier that’s the issue. I hope this is helpful. Source code / objects available on request.

    In each of the following pictures, the left-hand object is .blend->OgreXML->JME, and the right hand side is .blend->JME. The scene is lit by an ambient lamp and a directional lamp in JME – there is no lighting in the blender object.

    Simple cubes (above) both seem ok, except the OgreXML one is much brighter.

    Applying subdivide-smooth in Blender (above) leaves the object weirdly transparent in the OgreXML import, but it looks perfect in the .blend import.

    Next adding a surbsurf modifier, above, has no effect on the .blend, but does on the ogre import. The transparency issue still remains.

    Applying the above subsurf modifier, so it changes the mesh and removes the modifier, fixes the subsurf modifier for the .blend import. (The colour change is incidental.)

    Finally, our corrupted geometry problems arise when a second modifier is applied: Multiresolution. I use this to improve the smoothing, but apparently it sends JME haywire for the .blend import.

    In summary, the problem I originally reported is due to the Multiresolution modifier breaking .blend imports. The operator does not cause similar problems for the OgreXML import, but for some reason I’m getting undesired transparency in all Ogre XML examples shown here.

    I hope this helps to improve the importer.

    #
  • Profile picture of normen normen1290p said 2 months, 4 weeks ago:

    Thanks, I guess this will be helpful, yes.

    #
  • Profile picture of erlend_sh erlend_sh132p said 2 months, 4 weeks ago:

    Thanks for taking the time to make such well thought out issue reports @peterz . It really makes a difference.

    #
  • Profile picture of Kaelthas Kaelthas57p said 2 months, 4 weeks ago:

    Hi @peterz

    thanks for the test case. I’ll look into it tomorrow.

    As for the modifiers in blender importer.
    This is the issue I didn’t improve much. There are basic structures implemented that will allow to extend modifiers import in the future.
    The reason I didn’t pay much attention to modifiers is that they can be easily applied and the final model exported without them
    giving you the required effect.

    I will of course try to support as much modifiers as I can but that will need time.
    So be patient ;)

    #
  • Profile picture of peterz peterz7p said 2 months, 4 weeks ago:

    @normen and @erlend_sh – you’re very welcome, thanks for making a great game engine!

    @Kaelthas – thanks for looking into this. As I found above, the .blend importer generally does a great job, it’s only the multiresolution modifier that upsets it :-) Note that in my final example above, the modifier was applied before saving the .blend, so I can only assume it leaves the geometry in some weird non-standard state!

    Keep up the good work :-)

    #