Blender->jME textures question

Hello!



I’ve been struggling… Thrashing my way through Blender’s excellent interface… :stuck_out_tongue: Trying to get textures from blender to export into jMonkeyPlatform to view them before converting them to j3o. I’ve found that as soon as I attempt materials with textures, I’m unable to view or convert the scene I exported and the “Loading Model” progress meter just loops forever. Using vanilla, colored materials in the material file I’m able to view it just fine, so it’s not the model. Is there some trick to getting simple textures to export? Or is this just something you have to do by hand in JMonkeyPlatform?



Oh and one other strangeness is that my scene is named base.scene. I have a material file named base.material, and when I go to view the model it complains about a missing Scene.material. If I rename it to Scene.material, it complains about there being a missing base.material! Maddening! :stuck_out_tongue: I just copy the damn thing and have two of them to get by this, but what am I doing wrong there? :stuck_out_tongue: (This is with simple color material files)



EDIT: This is in blender 2.49b for the record. Not ready to learn another damn convoluted interface. One is enough :stuck_out_tongue:



~FlaH



Crazy ass material file incoming:

[java]

material FloorMat.001

{

technique

{

pass

{

ambient 1 1 1

diffuse 0 0 0

specular 0 0 0 0

vertex_program_ref Ogre/BasicVertexPrograms/AmbientOneTexture

{

param_named_auto worldViewProj worldviewproj_matrix

param_named_auto ambient ambient_light_colour

}

}

pass

{

ambient 0 0 0

iteration once_per_light

scene_blend add

vertex_program_ref Examples/BumpMapVPSpecular

{

param_named_auto lightPosition light_position_object_space 0

param_named_auto eyePosition camera_position_object_space

param_named_auto worldViewProj worldviewproj_matrix

}

fragment_program_ref Examples/BumpMapFPSpecular

{

param_named_auto lightDiffuse light_diffuse_colour 0

param_named_auto lightSpecular light_specular_colour 0

}

texture_unit

{

texture FilthyBrownBricks-NormalMap.png

colour_op replace

}

texture_unit

{

cubic_texture nm.png combinedUVW

tex_coord_set 1

tex_address_mode clamp

}

texture_unit

{

cubic_texture nm.png combinedUVW

tex_coord_set 2

tex_address_mode clamp

}

}

pass

{

lighting off

vertex_program_ref Ogre/BasicVertexPrograms/AmbientOneTexture

{

param_named_auto worldViewProj worldviewproj_matrix

param_named ambient float4 1 1 1 1

}

scene_blend dest_colour zero

texture_unit

{

texture FilthyBrownBricks-ColorMap.png

}

}

}

technique

{

pass

{

ambient 1 1 1

diffuse 0 0 0

specular 0 0 0 0

vertex_program_ref Ogre/BasicVertexPrograms/AmbientOneTexture

{

param_named_auto worldViewProj worldviewproj_matrix

param_named_auto ambient ambient_light_colour

}

}

pass

{

ambient 0 0 0

iteration once_per_light

scene_blend add

vertex_program_ref Examples/BumpMapVP

{

param_named_auto lightPosition light_position_object_space 0

param_named_auto eyePosition camera_position_object_space

param_named_auto worldViewProj worldviewproj_matrix

}

texture_unit

{

texture FilthyBrownBricks-NormalMap.png

colour_op replace

}

texture_unit

{

cubic_texture nm.png combinedUVW

tex_coord_set 1

tex_address_mode clamp

colour_op_ex dotproduct src_texture src_current

colour_op_multipass_fallback dest_colour zero

}

}

pass

{

lighting off

vertex_program_ref Ogre/BasicVertexPrograms/AmbientOneTexture

{

param_named_auto worldViewProj worldviewproj_matrix

param_named ambient float4 1 1 1 1

}

scene_blend dest_colour zero

texture_unit

{

texture FilthyBrownBricks-ColorMap.png

}

}

}

}

material BaseWhite

{

technique

{

pass

{

}

}

}

[/java]

The textures may not be packed into the blend file and have to be referenced with a relative location to the blend file, you can configure that in the blender output settings (the texture path starts with “//” when its relative). Also, they have to be in the same or a subfolder of the model (if you use the model importer) or in the assets folder of your project (when converting directly within the project).

Hello Again!



hmmm… I was working with the .blend in the same directory as the textures because I figured some pathing mojo like this was going to happen. But, I also have the textures in the same folder as the exported model files, so that should match up. Or is this in relation to the Scene.material and base.material issue? Thing that pisses me off about that is that I tell it to put the materials into base.material when I export, so… shrug :stuck_out_tongue:



~FlaH

I cant take a screenshot of the blender page where you see the export path atm cause I am at work… But an easy way to make sure the textures are in the right location with relative paths is by packing them once and then unpacking them with the “to /textures/ folder” option.

Hello again!



Arg k. So it’s probably my deficiency of Blender abilities getting me again here. *Grabs chair, whip and body armor and heads over to Blenderland… :stuck_out_tongue:



I’ll post back if I make any headway.



~FlaH

If it is the Blender → Ogre Exporter → jMP path that you are taking, I sympathize. I was trying to get one of my models through this path yesterday and wanted to put things through the computer screen on more than one occasion.



I can say that once you get the Ogre Exporter plug-in thing in Blender to put the right files into a sub-directory… then jMP will suck it in just fine. But that first step is key. You cannot manually rename the files afterwards… they have to be right in the first place.



To be right, you will end up with foo.material, foo.mesh.xml, and foo.skeleton.xml… plus whatever images you use as textures. If the Ogre exporter does not produce all of these things then something is wrong and you need to play with the exporter some more.

Hello Again!



Yeah, over the last hour or so I’ve got it to this point @pspeed. The exporter is spitting everything out in the directory I’ve chosen, but when I go to jMP and hit either ‘view model’ or ‘convert to j3o’ it just sits there and goes numb on me. The “Loading Model” progress spinner in the lower right just keeps on spinning, with no errors. Of course if I try to do it again I get an error, but it’s because the file is in use :stuck_out_tongue: Is there a way to cancel this process/task anyway? I mean, when it infinite loops like this I end up just closing jMP and restarting it which is a PITA.



I’m a bit clueless at the moment as to what is wrong and a little burned out from trying. Oyie XD



~FlaH

I also had to close and restart jMP about a hundred times. Also, sometimes it seemed like there was some errant ogre related .exe process running that I had to kill… but I don’t know who starts that or why.



So, just to confirm… your directory was empty before, you ran the exporter, then it had everything you needed? ie: there was no manual placing of textures there or anything like that?



And are you running with the latest jmp updates?

Hello Again!



Indeed started from scratch with an empty directory. Generated all of the mesh xml files, all of the filenames look clean and they all have some size to them at least. Scene xml is there, material, and the png’s containing the textures. And I updated jMP this morning to be sure, because I was fighting yesterday too and thought maybe I ought to give that a go :stuck_out_tongue:



Now, having said that, I haven’t dumped all of the files straight into jMP’s workset of directories. I normally sling everything over there when I’m ready, but I mean, how could it even change? I don’t see any pathing inside the files and everything is supposed to be in the same directory anyhoos?



Hang on and I’ll give that a shot.



EDIT: No change/difference. Spaces out to the loading spinner wheeeeeee



EDIT2: heh, I wonder if it likes that dash in my texture filename. It’s in the material in the original post.



~FlaH

You did read this, right?

Hello Again!



I have read that document before, but I read it again. It did point out there was an output section in jMP which wasn’t up by default. So I pulled that up and what I saw was:



[java]

Unsupported pass directive: vertex_program_ref

Unsupported pass directive: {

Unsupported pass directive: param_named_auto

Unsupported pass directive: param_named_auto

[/java]



I’m guessing that crazy material it generated is choking it? I’m playing with some things with the material now… All I wanted was a colormap and a normal map and bam, crazy as hell material generated… :stuck_out_tongue:



~FlaH

Hm… normal maps in OgreXML dont work really good I think… Just export the color map, create a j3m material in jMP and then add the normal etc. maps there.

Yerp. That did it. On removing the normal map I ended up getting the error:



[java]

Unsupported pass directive: emissive

Unsupported texture_unit directive: colour_op

[/java]



However, that was much easier to figure out how to clip out of the material file, and then it loaded. I guess there’s some quirks I need to workout for level design paths from Blender to jMP. This was my first attempt in actually sending meaningful materials from Blender to jMP since I usually just assign some bland, generic SolidColor to everything from within my application.



So wait, now that this is working. I’m a touch worried. I’d planned on just doing everything from Blender and importing it over, but if I have to do tweaks on the jMP side, how do I get back to the Blender side? Say I make a level, and go, “ah crap this corridor needs some work,” but I’d done the finalizing work in jMP already… So I’d have to go back to Blender, fix it, export it, redo all the prior work again in jMP, only to realize I effed something else up… etc etc… That workflow is… messy at best?



Not knocking anything, just wondering if I’m seeing/doing this wrong.



~FlaH

If it helps… for whatever reason, the model I was using I had to specify “Game Materials” instead of “Render Materials” when exporting. I’m a clueless blender noob so I have no idea what that means but that’s how I got my textures to work.



Edit: D’oh… didn’t see your follow-up.

tehflah said:
Say I make a level, and go, "ah crap this corridor needs some work," but I'd done the finalizing work in jMP already... So I'd have to go back to Blender, fix it, export it, redo all the prior work again in jMP, only to realize I effed something else up... etc etc... That workflow is... messy at best?

Well, its kind of like that at the moment, it gets worse the less of a real plan or workflow you have there. At the moment an example workflow looks like this (inconveniences are italic):

First you create a basic layout for a "level"
- Create and edit multiple models for houses, terrain parts etc. with diffuse map, normal map and animations in blender (model) and photoshop (textures)
- Export the model with only the diffuse map enabled
- Import/Convert the models in jMP
- Create a j3m file for the material of the models and add the other textures and special settings
- Add a CollisionShape in the SceneComposer
- Edit userdata/settings
- Create a scene by linking multiple separate models into a base scene file

So then you try around with the result, and find out something needs to change. A change in a texture is easy, just edit it in photoshop and next time you load the model in the SceneComposer you see the change. But what if you find out the layout of a house needs to change or an animation looks bad?

What you have to do is:
- Edit the model in Blender
- Export the model again
- Import the model in jMP
- Apply the j3m to the model (the changed settings are still saved in the j3m, so they are not lost)
- Add the CollisionShape in the SceneComposer
- Edit userdata/settings

After that you have the change in your game. So this is how it is at the moment really but of course the SDK aims to change that as well at some point :)

In the Future what will happen is:
- Edit the model in Blender
- The model gets imported directly from the .blend file
- All major changes to the j3o are stored in the j3odata file that exists for each model
- A change in the blend file will be recognized on save and the model will be imported again, the changes will be applied again

Cheers,
Normen

I could try adding some “guesses” to the material importer to get the normal map, however this won’t help much. If you want to take advantage of jME3’s specular map feature for example, it won’t work with the OgreXML materials.

Our only option at this point is to support the .blend format as fully as possible and that way we can use OgreXML for anything thats not Blender.