OpenB3DMax Roapmap

[ms62]

markcwm,

it seems my problem with loading MD2 model was not the scale, it was using LoadMesh instead of LoadAnimMesh. Openb3d doesn't have LoadMD2.

[ms62]

Just a question. Instead of relying on assimp, as it has dependencies, why not choosing a commonly used and tested 3d format like fbx as default for openb3d? Sometimes having too many choices is bad thing. Having just one good file format will create one good quality piece of work.

[markcwm]

I haven't got AC3D, I will have to have a look at it. Ultimate Unwrap is a great converter as it has lots of formats. Animation will be added soon, first for the default formats then to the Assimp wrapper. Actually, I've changed my mind about X now so I'll try to improve it, maybe add a binary loader.

I recommend using Bmx NG 0.87 release then to use Bmx BRL/legacy only for testing if you think you've found a bug with NG. The next step would be to test with Bmx NG latest source and then post an issue on Github or on the Syntaxbomb board Brucey's Modules.

Yes you're right LoadMesh doesn't work with MD2, this is because the library assumes MD2 to be animated only, there is no code for the loader in LoadMesh. I haven't added a native MD2 loader yet, I'm in the process of doing just that. The commands "LoadMeshFormat" are temporary, there will be a flag so you can choose library or native/Bmx loaders.

FBX is a complicated format and I'd rather avoid adding any new default loaders, besides you can easily customize the Assimp wrapper to only build the FBX loader or whatever else you want, it's in the Readme.

[ms62]

Which 3d file format you have chosen to be the default one, or to be the main one for openb3d in long run, something like after 5 years? Or, to say, you like openb3d will be known for? You can invent yours, but modelers must support it or you need to provide loader for each of them.

Most 3D modelers support obj and fbx. The best 3d modeler, imo, is Maya and it supports both. However, it is up to you; converters have advanced and it seems they do good job.

[markcwm]

B3D is the default file format as in Minib3d and Blitz3d, it supports skeletal animation and 2 uv sets for lightmaps but if speed becomes an issue then MD2 is supposedly faster. B3D is superior to 3DS as it only supports hierarchy animation (no vertices). X supports hierarchy and skeletal animation but the loader needs a rewrite. I have no intention to write a new file format as there are too many already. OBJ doesn't have any animation and has only 1 uv set. I think Maya is very expensive but I'm sure it's great.

[RonTek]

B3D is the default file format as in Minib3d and Blitz3d, it supports skeletal animation and 2 uv sets for lightmaps but if speed becomes an issue then MD2 is supposedly faster. B3D is superior to 3DS as it only supports hierarchy animation (no vertices). X supports hierarchy and skeletal animation but the loader needs a rewrite. I have no intention to write a new file format as there are too many already. OBJ doesn't have any animation and has only 1 uv set. I think Maya is very expensive but I'm sure it's great.

I agree, but since it follows Blitz3D overall, I think it should be B3D only format all the way. You could ignore the MD2, X and Obj stuff, B3D is a complete and nice 3D format. I guess if you're following the complete command set (LoadMD2, etc.), you need to support it.

[ms62]

I don’t think that following Blitz3D exactly is reasonable, but sticking to one file format reduces the workload and helps reaching the final goal faster. Since b3d models  already work and are supported by openb3d, it makes sense to rely on that and spend time on other the issues.

One issue is to make applying shadows easier. I will look at the code examples that are in openb3d folder to see how I can use them for my app. I am sure I have to eliminate objects of the scene to get to the  core of the implimentation. That takes time. I wish there was a simple two objects example, one a box and the other a plane to see how it is done. Now I have to do open heart surgery on them    Demos are not good tutorial. They are actually very bad tutorials. In other words, when features of a product are demonstrated, those demonstrations are not tutorial. They may actually turn off the beginners, while atract experienced customers.

[markcwm]

Yes, you're right okay, here's a basic stencil shadows example.

Code: [Select]

' stencil_shadows3.bmx
' stencil shadows

Strict

Framework openb3d.B3dglgraphics

Graphics3D DesktopWidth(),DesktopHeight(),0,2

Local camera:TCamera=CreateCamera()
PositionEntity camera,0,0,-15

Local light_piv:TPivot=CreatePivot()
Local light:TLight=CreateLight(2,light_piv)
PositionEntity light,25,10,25

Local plane:TMesh=CreateCube()
ScaleEntity plane,25,0.1,25
MoveEntity plane, 0, -2, 0
Local tex:TTexture = LoadTexture("../media/Moss.bmp")
EntityTexture(plane, tex)

Local cube:TMesh = CreateCube()
Local tex2:TTexture = LoadTexture("../media/test.png", 0) ' solid
EntityTexture(cube, tex2)
Local cube_shadow:TShadowObject=CreateShadow(cube)

Local alpha_piv:TPivot=CreatePivot()

Local cube2:TMesh = CreateCube(alpha_piv)
PositionEntity cube2,-5,-1,-5
EntityTexture(cube2, tex2)
Local cube_shadow2:TShadowObject=CreateShadow(cube2)

Local alpha_cube:TMesh = CreateCube(alpha_piv)
PositionEntity alpha_cube,5,-1,5
Local alpha_tex:TTexture = LoadTexture("../media/alpha_map.png", 2) 'Change this to 0 or 1 for correct depth testing
EntityTexture(alpha_cube, alpha_tex)
'Local cube_shadow3:TShadowObject=CreateShadow(alpha_cube)


While Not KeyDown(KEY_ESCAPE)

TurnEntity alpha_piv,0,KeyDown(KEY_D)-KeyDown(KEY_A),0
TurnEntity light_piv,0,KeyDown(KEY_LEFT)-KeyDown(KEY_RIGHT),0
TurnEntity cube,1,1,1

CameraClsMode camera,1,1 ' by default alphamaps get blended with shadows
RenderWorld

Text 0,20,"Arrows: turn light, AD: turn alpha cube, Memory: "+GCMemAlloced()

Flip(1)
GCCollect

Wend
End


[ms62]

Yes, now I see its simplicity. Thanks.

[markcwm]

@Angros, I've been looking at particle batch rendering as enabled by SpriteRenderMode 3 using point sprites to supposedly improve render times. It has some serious problems, first it depends on camera angle as to whether they are visible, they flicker constantly, they scale based on distance to the camera, there seems to be no way to control them independently. I've tried some GL things but nothing changed. Is there something I'm missing? Thanks.

[angros47]

Batch point sprites can leave a trail behind them: basically, the trail is made by other sprites, that will fade after a while (and that can slowly move in the direction set with ParticleVector, to simulate fire or smoke). You can control the main particle, not the temporary particles used to make the trail (and those particles are created only when in view). If you want several sprites that can be controlled individually, duplicate  them with CopyEntity, and they will work as regular sprites (but much faster). Also, each of them will be able to leave a trail behind (the particles that constitute the trails are managed automatically by OpenB3D)

I have the impression that you tried to create a single sprite with a long trail, mistaking the trail sprites for real ones.

[RonTek]

Great update and now working with NG! I got an older NG version and I only tried 32bit, but still builds and runs the examples ok, just need to update timer.mod and timerdefault.mod.

[markcwm]

Just bumping this to say Yay! You can now load animated B3Ds from zip or incbin using the native loader LoadB3D, see standard/load_b3d and minib3d/bones examples.