Really large 3D scenes - pushing my luck...
Blitz3D Forums/Blitz3D Beginners Area/Really large 3D scenes - pushing my luck...
| ||
| I guess I'm having memory issues. I get a Memory Access Violation when I try to load my scene file. It had worked under the demo version of BB3D, but now it doesn't. It's a 43MB .x file. I tried saving it as a .b3d file (Max5 & exporter) Size was 16MB, still won't load. Frustrating. I wanted to see how far I could push this application since I have 12 other .x files about 8MB apiece that are skinned meshes with 184 bones in them. I have my own visual basic 6 code, but the frame rate stank. The demo encouraged me to purchase this full version because it worked STELLAR in the hacked mak/castle demo -- I had left the terrain map in and it still ran really fast!!! I'm trying to make a movie here... Can I expand the available memory to B3D somehow??? |
| ||
| Can I expand the available memory to B3D somehow??? No. This isn't the problem, anyway: B3D applications only have the same memory limits as any other 32-bit application (2GB, cannot be crossed in any practical way). My best recommendation for loading would be to simply split things up. What are these meshes that they have to be loaded as single files? Break 'em apart into scene components and see if that works a bit better. You might need some kind of scene manager, but it will probably be worth it. Note that you can export animations as armatures of meshless pivots if necessary, and then parent meshes or bones onto these, so the scene doesn't need to be one huge file simply for the purposes of animating it in one go. In terms of total quantity 96MB is nothing for a loaded and running application, but the loader might choke on it if it's one file. Also, don't use the .x format unless you can verify that it's the DirectX 7 version (which I'm pretty sure doesn't support bones, and even if it does the Blitz3D loader won't load them). The .b3d format is best in all circumstances. As for performance, Blitz3D animates bone deformations in software. This is slooooow for large numbers of boned meshes. Do consider switching smaller/background animated elements to something with better performance like MD2/3 - bones are really most useful for their dynamic nature and a movie doesn't need that, so if you can spare the memory a vertex-animated mesh will render much more quickly. (On the other hand, if it worked before it worked before, so...) Do you even care about performance for a movie? Render frames for as long as you want in top quality - it only has to be done once, after all! |
| ||
| Oh, please talk to me a bit... You clearly know what you're talking about! 1. I read somewhere that the limit was 65K verts. Is this correct? 2. My x files are pretty generic 3. By skinned mesh, I meant bones in an x file - skin weights 1.0 only 4. Just 12 maximum actors, the rest would be dummies. 5. Live rendered movie would be preferable - I have an AI |
| ||
| I can split up my scenes. So OK. How about a theoretic maximum for the application? My card pulls 67.5MV/S fill rate. I was able to load skins in the demo - haven't tried it yet in my purchase copy. |
| ||
| 1 more thing - My AI animates the bones from an .ani file, so I can have a large library of different motions. I don't use the .x animation |
| ||
| Does load the actors ok. How can I reference their bones by bone number- FindChild is all I've got right now. |
| ||
| I read somewhere that the limit was 65K verts. Is this correct? This is per-surface, not per-mesh (a mesh can have an arbitrary number of surfaces) and certainly not per-scene! On some cards it may be lower (this isn't really Blitz's fault, more of a graphics system limitation). Unless you have unusually intricate single objects, this is unlikely to be a problem for you. There is no upper limit to the total number of surfaces except performance and your patience. I'm afraid I don't really know what I'm talking about when it comes to .x files though other than that they're not "fully" supported by B3D, whereas .b3d is (obviously, being the custom format). I'm not aware of .x being able to load as deformable meshes, but must check this. ... as for bone number, if this is a .x thing it won't be preserved. You've got child index (i.e. the array index of a child in its parent's vector of children - non-hierarchical identifier, likely not helpful, possibly not even predictable) and you've got name, used by FindChild. Perhaps you can programmatically rename bones to their number in your editing program? |
| ||
| My scene mesh has 140K triangles. I gave up on that for a while... Actors: So, I'm now not able to rotate any bones... I loaded it as: For t=0 To 12 actor[t]=LoadAnimMesh( "d:\desktop\new folder\myter.x" ) EntityType actor[t],TYPE_CHARACTER,True ScaleEntity actor[t],.15,.15,.15 MoveEntity actor[t],(t*5)-(6*5),0,-25 Next Good. They're there. For t=0 To 12 RotateEntity FindChild(Actor[t],"Jaw"),Rnd(0,-25),0,0 Next isn't doing anything. Correctly placed in the main look - tested on the actor itself. It also says entity not found on one of my placeholder bones. (Bone number: I was only hoping to move ALL of the joints to see how much things slowed down when I did.) Last edited 2012 Last edited 2012 |
| ||
| Tried the bliz exporter for max5, and I guess it isn't exporting the hierarchy correctly because I didn't use actual BONES on the mesh, but parent/child dummy objects - max allows this. Bones are very inconvenient since you can't reposition them without affecting all of the child bones - - - and you can't change their length. It's also inconvenient to use an actual SKINNED MESH in max5, and I just use vertex colors assigned to dummy points that are the same color when I export a skinned mesh to an .x file. My hand-written (took a year) macroscript for Max5 creates the .x file that is perfectly valid in directx 7 or 8. This was all working FINE in the demo. And you know, this character has transparent polygons for the fur and whiskers that we haven't addressed yet. Now I did buy the fastextensions and was able to address anisotropy/sharpness problem with fences and such. BlitBasic3D Demo 1.83 BlitBasic3D Purchase 1.99 Blitz3d Exporter 0.7 Last edited 2012 |
| ||
| If all else fails, you can always roll-back the installed version of Blitz3D to match the version in the demo? You should have access to every released version as an update from the "Product Updates" page, for addressing exactly this situation. vertex colors assigned to dummy points that are the same color when I export a skinned mesh to an .x file. I'm totally lost at this point: how does that help with skinning? Do we have different definitions of skinning? I was assuming you meant deformation... I was only hoping to move ALL of the joints to see how much things slowed down when I did You don't need to move all of them for this test: the way the software animation works is such that the bones only have to be present and engaging the animation system (if you're not using the builtin animation system then that's one thing cut out already). You should only need to move the one around for test purposes (basically it rebuilds rather a lot of stuff it doesn't necessarily have to, for simplicity over massive scalability). isn't doing anything. Correctly placed in the main look - tested on the actor itself. Case sensitivity? Exporter appending extra characters? Exporter doing something else to the names? |
| ||
| I'll try a roll-back. My exporter: When I write an x file with my exporter in max, all it has to do is look at the mesh's unused vertex colors and match them to the 'bone' colors to create the file (short cut). To move a bone, all I have to do is drag the dummy point to a new location to recenter it where I want it. Yeah, the hierarchy would have to update if I picked a bone at the start. Not case sensitivity. I found the b3d file spec, it's VERY SIMILAR in structure to an .x file. I'll try rewriting my macro to output one. http://www.blitzbasic.com/sdkspecs/sdkspecs/b3dfile_specs.txt Last edited 2012 |
| ||
| Aha! - no rollback yet - The exporter had these checks required: Scene Root Meshes Normals Materials Textures Relative Paths Bone Meshes Export Bones Preserve Key Frames (Probably not needed) and NOTHING ELSE checked. |
| ||
| Skeletal mesh problem seems solved with b3d exporter. Problem is now only transparency. There was a fur.tga file, tried also fur.dds. No good. Mesh has 5 materials assigned to it. Only the one is transparent. Should I be using a dds or tga spritesheet type of file?? Currently running latest update with no difficulty. Last edited 2012 |
| ||
| Are you exporting the texture flag to enable the alpha channel? If so, perhaps you could try setting the EntityFX for the child mesh in question to force alpha blending? (Don't do this for anything that isn't totally convex.) |
| ||
| Looks to me like the relevant body parts aren't being exported at all. I hexed the filename to a .bmp (a blank white bitmap) and still no fur body parts showed up. [Update] I had set opacity to 0 in max. Now they show up as solid even with the tga map. TextureBlend ttex, 1 ;Alpha EntityTexture FindChild(actor[t],"z_FurHeadL"),ttex ;Does't work - not a model EntityFx: 1: full-bright 2: use vertex colors instead of brush color 4: flatshaded 8: disable fog Nothing listed about alpha [RESOLVED] People using 3DS Max 5 should go here: http://www.onigirl.com/pipeline/ and download the package - it makes including brushes and alpha data easy to do. [UPDATE] Noted the memory issues above probably caused by my graphics card. See my other sequel post to this one 'Really large 3d scenes revisited" Last edited 2012 |
   |