• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by JCPalmer

  1. Also, in 5.6.2, you can specify a subdirectory for the location of textures. Not sure that is your problem, but reason to ditch 4.6.1.
  2. Also, unless it is a typo, the exporter version is a 5.6.4. If that should have been 5.6.1 not 4.6.1, probably not a big deal. My personal opinion of ImportMesh is quite low. This forum is littered with mistakes where someone accesses newMeshes[0], and it is not the mesh they think it is. Append & Load might do the same, but people less often blindly pick [0]. If a .blend has a camera and or lights which are unwanted, temp delete them prior to export to avoid ImportMesh. I can see you are not doing that, but completely ignoring the callback for accessing can illiminate many problems, & also facilitate multiple Appends which can get ugly using callbacks. getMeshByName in an ExecuteWhenReady is an answer to your access question. BABYLON.SceneLoader.Append(url, "myfile1.babylon", scene); BABYLON.SceneLoader.Append(url, "myfile2.babylon", scene); scene.executeWhenReady(function () { const mesh = scene.getMeshByName("male1"); });
  3. Since you had rotation being performed on the load of meshes in your the previous topic while loading, & your screen shots shows un-applied rotation & scale, I think you are just making what is called a mess. Just try straighten things out by applying transforms in Blender, commenting all rotation in loading & make sure you BJS camera is not upside down. Parent the other 2 messes to the third, or at least make sure they share the same origin, or rotating is probably not going to work.
  4. An export as is: I see missing textures, not sure if you have them. I remove 'red paint', it worked. i remove '15 - default', it worked. i remove 'Deck Green', stairs now turn all yellow, but it worked. i remove '07 - Default', stairs now turn white, but it worked. i remove 'White', stairs now turn black, but it worked. i remove 'Dark Grey paint', stairs now green, but it worked. i remove 'Deck Green', & now have no materials, ut worked. Seems old that the color should change on the whole mesh though. For meshes with multiple materials, they should not be the same vertices for each material. Reloaded .blend, put mesh into edit mode, hit select button while each material selected. 'Deck Green' is used for all the vertices.
  5. Then there would be only one GL context. Not sure about an effect to frame rate, but should be less resources. One other thing you might try is perhaps only actually render a scene, when the mouse is inside a canvas. Kind of application specific, and would not work for scenes with animation. There is only one mouse though, so could be a sneaky cheat for some.
  6. @ozRocker, I did notice this when looking at Blender 2.8 dev docs. It is not like I was going to do this, but for that. Particle "Rewrite" seems coming.
  7. What version was this blend saved under? Game engine has been around a while. What happens when you switch render to Game Engine?
  8. No, for anything in dev for a couple of years, less than 30 days is not too early to see what is now broken. Might be too early to fix problems unless it is easy to guess, though.
  9. I am not working in this area. MergingMeshes of the same material already works with both meshes & clones. One area which might make it easier is optimizing materials. It is just a loop thru scene.meshes, but why should everyone need to do it. Maybe, a method on Material.mergeMeshes(exclude? : array<Mesh>) : void. If you had a bunch of tree meshes or clones, call it like: scene.getMaterialByName("tree_material").mergeMeshes(); If no one uses it, then it would be more bloat. Strawman, not validated: public mergeMeshes(exclude : array<Mesh> = []) : void { const selected = new Array<Mesh>(); for (m in this._scene.meshes) { if (m.material === this) { let ignore = false; for (e in exclude) { if (m === e) { ignore = true; break; } } if (!ignore) selected.push(m); } } Mesh.MergeMeshes(selected); }
  10. Well, I think they have been saving it up. Nuking 2 renders got them just re-architecting everything. They need these temporary meshes themselves. Did some looking around. Changing this to get better frame rates. I am going to switch to developing this branch while running on 2.79. There was one change I need to make for the first commit, a name change from 'Lamp' to 'Light'. I un-did this, but not committing. The rest of the changes to loading still run on 2.79. In 2.79, they first implemented PrincipledBSDF node. This is never going to put into the pre-2.80 release. Going to rip out anything for the old render first. Just more crap to wade thru. BTW, if 2 different materials could be expressed as either a BABYLON.StandardMaterial or BABYLON.PBRMaterial, should there be a preference? Maybe, Standard because: performance WebGL 2 Getting boned by Jobs from the grave etc
  11. After commenting out the 30 or so lines which create the materials, the very next line runs us right into a brick wall: # process all of the materials required #recipe = BakingRecipe(object) self.billboardMode = BILLBOARDMODE_NONE # BILLBOARDMODE_ALL if recipe.isBillboard else BILLBOARDMODE_NONE #if recipe.needsBaking: # if recipe.multipleRenders: # Logger.warn('Mixing of Cycles & Blender Render in same mesh not supported. No materials exported.', 2) # else: # bakedMat = BakedMaterial(exporter, object, recipe) # exporter.materials.append(bakedMat) # self.materialId = #else: # bjs_material_slots = [] # for slot in object.material_slots: # None will be returned when either the first encounter or must be unique due to baked textures # material = exporter.getMaterial( # if (material != None): # Logger.log('registered as also a user of material: ' +, 2) # else: # material = StdMaterial(slot, exporter, object) # exporter.materials.append(material) # bjs_material_slots.append(material) # if len(bjs_material_slots) == 1: # self.materialId = bjs_material_slots[0].name # elif len(bjs_material_slots) > 1: # multimat = MultiMaterial(bjs_material_slots, len(exporter.multiMaterials), exporter.nameSpace) # self.materialId = # exporter.multiMaterials.append(multimat) # else: # Logger.warn('No materials have been assigned: ', 2) # Get temporary version of mesh with modifiers applied mesh = object.to_mesh(scene, True, 'PREVIEW') The to_mesh() allows us to export the mesh after any modifiers have been applied, e.g. armatures, edge split, smooth, mirror. While it is not really a great idea to export a character with the skeleton posed, being force to apply the other modifiers is bad. It did not say there was no to_mesh() anymore. There is now a problem with the first argument: There is no API documentation for 2.8, but the current doc clearly wants a scene for arg 1. I do not know what a Depsgraph is, but in the doc for a scene, has one for a property, or did anyway. Passing that was not acceptable. Google has commenced. Turns out gltf exporter already reported the problem. The saga continues.
  12. World: Working through the running of the exporter on 2.8, World is the first thing to run. It seems that Mist & ambient color have bit the dust for 2.8. I now hard code a mathutils.Color((0.2, 0.2, 0.3)) for ambient. Mist did not actually error, but there is no-longer a section in the world properties. I left the code for mist for now, but if there is no UI for it, eventually it will start to error. Since there is already a section for additional properties for mist by the exporter, the lost properties might be added there, or the additional properties deleted. Game Engine: With the removal of game engine, game_settings.face_orientation & game_settings.use_backface_culling are toast. That corresponds to Billboarding & back face culling in export. While it does not seem likely culling might really be gone forever, that would be a huge blow, if you could not turn it off when needed. Materials: Everything is changed here. Am just going to keep the exporter from exporting materials to see if there are any more problems not related to materials. Stay tuned.
  13. No hurry. I will begin by using a MakeHuman import using cycles. Cause that has to work. I'll branch out as I get something to run. Just freshened branch. Going to rip out anything that does not run. Start adding in the material area.
  14. gltf is Apache licensed, so we could steal anything we might want from there. I not exactly sure what you mean by a an exporter POV. I am leaning towards making a nodes directory. In the directory, each type of Node would have it's own class & file name, if we support it. E.G. Many files would be very small, but once made would not likely to need to be changed. This suits a repo very well. The constructor for a node class would get passed in the Blender node instance. The constructor would be responsible for parsing any fields used & do anything to get the values prepped, as required, to be output in the 2nd pass. If something about this node means that this material must be baked, then the construct would set self.mustBake = True To handle the chaining of nodes in a single spot, all node classes would inherit from I am hoping this constructor, which would run prior to the sub-classe's, would process each of the input nodes to the current node. This would effectively go all the way down the chains, if the original instance is called with the node with no parent: for node in material.node_tree.nodes: if node.parent is None: self.node = AsbtractNode(node) Just writing directly into this topic, the straw man for would be something like: def __init__(self, shader): self.mustBake = False self.inputs = [] for input in shader.inputs node = AbstractNode.determineNodeClass(shader) if node.mustBake: self.mustBake = True break else: self.inputs.append(node) # end of super class constructor, sub-class constructor now runs @staticmethod def determineNodeClass(shader): shaderName = shader.bl_idname if shaderName == 'ShaderNodeBsdfPrincipled': return BsdfPrincipled(shader) elif shaderName == 'ShaderNodeBsdfDiffuse': return BsdfDiffuse(shader) ... else: return MustBakeNode(shader) There may also need to pass the parent or type of input into the constructor. Each node class would be responsible for writing their part of the material.
  15. This exporters branch was made a while ago and changes have occurred to master for files in Blender. Is this a way to get last versions of all files (only blender files matter) from master? Seems right, but not positive.
  16. If you pass in the function you wish to run as an argument to createCameraView, then call assign it as the callback, then ditch the let, your anonymous function & the return.
  17. Just use a plane mesh. It only has 2 faces. You can disable it right in the exporter Custom properties UI, which should perform identically to empties. There is also a place to add tags which get exported. No need to assign a material.
  18. Wow, I knew there was a problem when only one or 2 of the principled properties had a name in BJS. We are going to need some type of node analyzer to determine if PBR can be transferred, or the whole thing just needs to be baked. I think to get best results, perhaps we need to add an operation in the Materials tab, which creates the exact structure we support. It would probably not be laid out very well, at least initially. It would save work, and avoid baking at the same time. If a given did not have say a bump texture, you could just nuke the node. This is such a free form organization, it is not going to be easy.
  19. Yes, it would mean that I get what goes where in the export, and also documentation. Red line anything in the Blender that maps to nothing. Doc things that BJS has with no corresponding field could just be listed in text below.
  20. I think I asked for this before, but not in a specific topic. I need to know at the detailed level how Blender's Principled BSDF shader maps to BJS. The BJS relevant doc seems to be: Blender describes the shader here: There is no place in the Blender API docs which layout how to access / set this, but there is this:
  21. In my Skeleton & bone sub-classes, I interpolate from pose to pose. I was keeping translation & rotation out of root bone poses, and moving the mesh. When I did a demo scene for QI 1.0. I tried to do the worst thing I could think of, the opening pass of Simone Bile's floor exercise. Once a skeleton does a flip, coding becomes way too complex. That & other problems like "floating" caused me to use root bone for translation instead of mesh position for a test, which worked very well. I kept the rotation at zero for the test, however. When a new pose was being processed: The pose is decomposed into poseTranslation, poseRotation, & poseScale. currPosition = rootBone. getPosition(BABYLON.Space.LOCAL) targetPosition = currPosition.add(poseTranslation) Does anyone know if I should just do the same for rotation, or do I also need the amount of translation accounting for the rotation? I am really hoping they can just be handled separately, because if not this could get messy.
  22. Think @gryff would approve, were he still coming here. This would get a quarter of the of the question out of the Q & A section. Thought about reassigning existing topics till you got tired? I do not actually know what 'sbu' or 'DCC' stands for. The name could be better. I am half thinking subs under that: Blender, Maya, 3dmax, & General Loading might be good. Very few people use more than one. The closer highly related questions are, the better. If not, at least have a pinned topic, saying to tag gives options to further separate in the future.