Mark's 2nd new worklog!

Hi,

Ok, to clarify things a bit:

* Priority 1 is writing a new 3d lib, with an underlying 'b3d-like' design.

* Priority 2 is wrapping it up as a Max module.

* Priority 3 is wrapping it up for other languages.

When I mentioned 'Blitz3D2' below, I was thinking about swapping out the current 3d engine in Blitz3D for the new one - language/IDE remain the same. Haven't given this much serious thought (and probably shouldn't have mentioned it) as Max/3D kind of renders the idea redundant. Still, there may be people who prefer the simpler b3d language and ide? Community response so far seems to indicate this is indeed so, but it still a 'maybe' for now...

And...there is definitely NOT a new language coming!

Some tech stuff (all subject to change of course):

While this engine wont be identical to b3d, there is one thing I want to recapture from b3d: the 'everything is an entity' concept. To be more precise - 'everything with a matrix (ie: with position/rotation) is an entity', and as such has a single parent and 0 or more children.

This breaks many of the 'design rules' I've read over the years regarding scene graphs, but is just sooo sweet to actually use, and that's gotta count for something! I have tried various other approaches and messed with other systems, but these generally lead to a major increase in API complexity for a dubious amount of efficiency benefit.

Physics-wise, Max3d will have ODE support built-in. Support for other physics engines may or may not happen. So far, I've got body (things with mass), geom (collision shapes) and ball-joint entities happening. Currently, they rely on parent/child relationships to decide what to 'connect' to - eg: Adding a child geom to a parent body will link the geom to the body (and adding another child geom to THAT geom will too, etc) - but this could change in future if necessary with 'SetBody' style calls.

Some might find the idea of bodies, geoms and joints being actual scene-graph nodes a little unusual. But in practice, I just find it much nicer to use than a system that separates out the physics stuff - you can sort of 'construct' things in your head more easily.

Rendering wise, the surface/mesh system is also likely to change a bit. B3d surfaces actually contain a 'hidden' internal mesh (b3d 'meshes' are really a container 'meshmodel' for multiple surfaces) and I want to make this side of things public.

This allows for more flexibility painting the same mesh different ways - which is important because the old 'EntityColor/EntityTexture' stuff *will not* be happening. This basically involved 'blending' multiple brushes, but was very clumsy internally, introduced a nasty rendering bottleneck and would be practically unworkable in a multi-shader environment.

In fact, surfaces are currently 'proper' entities and exist solely to connect a mesh to a material (and provide a matrix). If you want a multi-surface model, you need to create a pivot and add a bunch of child surfaces to it.

Bottom line, code to knock up a cube+physics currently looks a bit like this:

mat=CreateMaterial()
mesh=CreateCubeMesh()
surf=CreateSurface()
body=CreateBody()
geom=CreateCubeGeom()

SetMaterial surf,mat
SetMesh surf,mesh
SetParent geom,body
SetParent surf,body

Bye!
Mark Sibly,
Blitz Research Ltd

Rendering wise, the surface/mesh system is also likely to change a bit. B3d surfaces actually contain a 'hidden' internal mesh (b3d 'meshes' are really a container 'meshmodel' for multiple surfaces) and I want to make this side of things public.

Mark's 2nd new worklog!

I really like the flow of updates that is going on here. I'm really happy with Marks new direction and can't wait to give him my money for said direction.

Physics-wise, Max3d will have ODE support built-in. Support for other physics engines may or may not happen. So far, I've got body (things with mass), geom (collision shapes) and ball-joint entities happening. Currently, they rely on parent/child relationships to decide what to 'connect' to - eg: Adding a child geom to a parent body will link the geom to the body (and adding another child geom to THAT geom will too, etc) - but this could change in future if necessary with 'SetBody' style calls.

When I mentioned 'Blitz3D2' below, I was thinking about swapping out the current 3d engine in Blitz3D for the new one - language/IDE remain the same.
Haven't given this much serious thought (and probably shouldn't have mentioned it) Max/3D kind of renders the idea redundant

I'm really happy with Marks new direction

This allows for more flexibility painting the same mesh different ways - which is important because the old 'EntityColor/EntityTexture' stuff *will not* be happening. This basically involved 'blending' multiple brushes, but was very clumsy internally, introduced a nasty rendering bottleneck and would be practically unworkable in a multi-shader environment.

So whats the point when max has already laid the foundations as the new blitz language?

but if you've ever reached a point in B3D where you wanted more than one list of the same type, you'll soon value the flexibility over the small amount of extra work.

* Priority 1 is writing a new 3d lib, with an underlying 'b3d-like' design.

* Priority 2 is wrapping it up as a Max module.

Priority 3 is wrapping it up for other languages.

When I mentioned 'Blitz3D2' below, I was thinking about swapping out the current 3d engine in Blitz3D for the new one - language/IDE remain the same. Haven't given this much serious thought (and probably shouldn't have mentioned it) as Max/3D kind of renders the idea redundant. Still, there may be people who prefer the simpler b3d language and ide? Community response so far seems to indicate this is indeed so, but it still a 'maybe' for now...

He's written some pretty great games, and in blitz3d. It's not the language thats holding you guys back from writing great games!

Do you think if max had better docs ie, when you press F1 it came up with a proper description and example code like in b3d, perhaps even with some "migration" notes, then people would warm to it quicker?

Do you think if max had better docs ie, when you press F1 it came up with a proper description and example code like in b3d, perhaps even with some "migration" notes, then people would warm to it quicker?

Do you think if max had better docs ie, when you press F1 it came up with a proper description and example code like in b3d

I hope that there will be FBX support as it's widely supported instead of some unknown proprietary format.

2. It is a closed format. They have (as yet) not published the specifications for either the ascii or binary versions, and have declared there is no plans to do so.
3. Some 3rd party support of the .fbx format (and most 3d modellers do now export it) has been acheived by reverse engineering .fbx ascii exported files.

I'd expect it to work flawlessly with Max and Maya as they're Autodesk.

developers are effectively only using a small subset of all the features available anyway

I'm sure Mark will have his own thoughts on which format he will concentrate on.

You mean like blitzMax does when you press F1 twice?

They are both general purpose formats that arent optimized for games.

If it comes out for Blitz3D Ill buy, Max I wont, Im sick of Max, its too much like C++ to be enjoyable.

If it comes out for Blitz3D Ill buy, Max I wont, Im sick of Max, its too much like C++ to be enjoyable.

I think he means he doesn't like the way BMax is OOP and has different features to B3D, like Strict, TClasses, etc.

If it comes out for Blitz3D Ill buy, Max I wont, Im sick of Max, its too much like C++ to be enjoyable.

#include <iostream>
using namespace std;
void main()
{
  cout << "Hello World!" << endl;   cout << "Welcome to C++ Programming" << endl; }

Print "Hello World!"

Anyhoo, I expect Mark is more interested in his own 3D format - like the B3D one - which gives him exactly what he wants.
Of course, nothing stopping someone else coming up with a converter...

For me, (aside from the 3D) its almost like b3d's base language, but comes with some really powerful extras.

And he HAS to use those because?.... Anyway, max isn't oop-only or anything, it simply has the capability, thats all.

The people know that programming BM without OOP
is hopeless. Because everyone uses it.

And so there
is no sourcecode they can read without learning it.

And they can't ask questions because the anwers will be in OOP.
"Plz, can you translate the code to procedural programming.
I dont't understand it."
Impossible.

To OOP or not to OOP; this is the question.

Many started using Bmax procedurally and many of those of did are still here using with OO techniques. Personally, I don't think that means Bmax procedural aspects are poor rather tha advantage of OO becomes more evident.

or the half-full answer, if youw ant to learn OO and use Bmax to it's fullest advantage then there's a lot of source code.

To OOP in my view.

But almost anything else just won't.