Mark is at it again

Am I the first one to post this?
http://blitzmax.com/logs/userlog.php?user=1&log=1043

Interesting stuff. Thanks Mark!

At last, there'll be swizzles.

The lack of swizzles has been holding me back.

:)

Looks like he's back to his old idea at tackling shaders, which I quite liked to begin with.
(being that I know jack-crap about programming anything outside the Blitz language)


I'm curious to know how scalable it'll all be on lower-end hardware in the end of things.


Regarding the naming conventions, I can't see why he couldn't just use both and leave it up to user preference which one they use.
(reminded me of Turing, how it had both a Color and Colour command <.< )

I prefer this way

For function naming. I prefer
brushcreate
brushdelete

instead of

createbrush
deletebrush

But I don't care enough for it to be any kind of bother - and if changing them around would hold up Max3D then it would be a bother!

I'm with Moraldi and dynaman on the naming convention.

English-wise I prefer CreateBrush than BrushCreate, otherwise I have to adapt to the language rather than the other way around.

Nice to hear about shaders too. I think he's taking the right approach with the lots of adjustable small-bits-of-shaders-joined-together type of approach, which is what the GLSL language pretty much implies by its structure.

What I want to know is what object organization method is going to be used in Max3D? Binary Space Partitioning? Quad-trees? Octal-trees? And also what about collision detection?

He said something when talking about physics:

I prefer ye olde:
SetBrushColor()

You can always wrap it like so:
Brush.SetColor()
..or something.

I prefer the oldschool naming convention, though I suppose it would scatter things around in the docs.

Not too sure about the idea of including scripting in the 3D engine. That's the sort of thing that annoys me about other 3D engines - they incorporate a lot of functionality that would be better incorporated at the programming end (to give greater control and versatility).

One question I would have in regard to this, is how well would the scripting engine integrate and interact with the functionality of the main program? Assuming a program was data driven, would it be necessary to end up with two scripting languages - one in the 3D engine, and one in the main program? I imagine not, but it's something that needs clarifying. I'd also like to know if there's a good reason for incorporating scripting in the 3D engine (better speed, better access to the 3D engine's functionality, etc), rather than making the 3D engine more accessible to a scripting engine incorporated in the main program

I'm with Beaker, keep it basic (and OOP plx)!

Hi,


Well, the 'scripting engine' (that term's a little vague for me...) will have exactly the same access to Max3d as will the host language, so it's not like you'll ever *need* to use it, or it will have some extra magic access or anything.

What I mainly like about the lua stuff at the moment is really just the debugging/testing potential it adds. In particular, I want to add a Quake style 'drop down' console to Max3d, and having lua as the 'console interpreter' will really be cool I think.

As for taking scripting further, eg: for event handlers like OnUpdate() or whatever, that's something I might well explore further down the road. But I can't ever see it being 'more capable' than just doing your own updating in the host language.

I am wondering, Mister Sibly, why have LUA for this scripting and not just make an interpreter for BlitzMax code? Or licence it from the BlitzVM people? Otherwise people are going to have to learn how to code in LUA. I'd rather just code in BlitzMax or a very similar dialect. Needing to learn another language to write scripts means it pushes the interface to a higher level of advancement required to use it.?

LUA is damn easy man...you will love it, trust me..and plus there are extraordinary good IDE's for it, for example Eclipse..I tell ya..LUA is a way to go..

And Lua is pretty much the standard when it comes to scripting languages for games...

This is strange! My theory is that Mark has spent the last year perfecting DNABASIC, cloned himself numerous times and we now have a hundred Marks working -- enough even that there is time left over to write *gasp* a worklog.


I prefer neither command naming conventions. Lower case letters with underscores in anti-grammatical order FTW!
(Yah, Linux... and C... has corrupted me).

For example, brush_set_texture, brush_get_color, brush_create...

Max3D is intended to be approached via language-specific bindings, correct? In that case, I think it would be most logical to go with the easiest command set for which a human can flip through documentation (searching text is important!), with "pretty" commands like CreateBrush left up to, for example, BlitzMax's bindings.

While we're on the topic of 3D engines forcing things upon people: Can a developer say "I don't want your stinking physics engine" and have it not only be unused in their code but also entirely unloaded such that there is plenty of room for another physics enging of their choosing? Would disabling Max3D's physics engine have to be an explicit choice, or would it be a seperate package that just happens to be consistent with the Max3D command set?

Thanks for all the worklogs, by the way, Mark! The frequent updates have been nice :)

For naming coventions I would say stick with the Blitz concept of using words in the order you would speak them ..

"I wish to set the brush color"
"After that I'm going to set the brush texture"

SetBrushColor
SetBrushTexture

Provided OOPers can still do:

mybrush:TBrush=CreateBrush(blah)
mybrush.SetColor 100,200,100
mybrush.SetTexture thistex

I'm with Gfk with the swizzles... Not having swizzles is the one single reason I stuck with 2D for all these years.

SWIZZLES FTW!!!

;)

Oh, i would try to make the commands sound nice, just take enough amigaish sounding, short and easy to be typed words and it will be nice, saying so "brush" is nice, even "thing" is but i would prefer a "brush.create", "brush.delete", "brush.copy", ... much more. I think it's really important how commands are defined and how they sound like. In Unity they never cared about this and so it's less fun typing code in there.

I'm not sure about the benefits of LUA. Is this built in for sake of that it can be acessed the same way for different languages? Otherwise i quite don't get why BlitzMax shouldn't be enough.

And i also hope that there will be out of the box support for simple vertex coloured shaders (working with fog) and transparent ones (single and both sided).

mybrush=New Brush()

That should be Brush.Create() silly :D

I'm pretty excited where mark is going with this, except for the whole physics thing, newton is already there pal!

I also prefer the oldschool naming convention, Migrating from old Blitz3d would be easier for users I reckon

Keep up the good work Mark, this is getting exciting :)

Go Mark ! :)

In something complicated like a 3d engine you need to find your way around the docs quickly - which helps productivity and is less frustrating. Looking for set or create is no good - better to have all your commands alphabetically listed. So if you want to look up the syntax for brush, then all the listed commands follow - BrushColour, BrushCreate, etc.

Whatever you decide, keep up the good work!

...and don't get bogged down in anything but the 3d module. ;-)

Could this be applied to the entire Max language to improve the debugger?

Good read. Looks like things are progressing swiftly.

I don't see the problem with commands being jumbled about. You can always create the docs to view by catagory.

Hurrah, multi layer materials!

I really really want to believe..... But.....

Looking good! I prefer the old naming convention (which if we wrap our stuff in OOP won't matter so very much either way I suppose).

If the documentation were to be in the Blitz3D category style (as Ross C mentioned) it would make it fairly straight forward to navigate.

I also like the idea of inlining / embedding the debugger ala Blitz3D.

I would also be interested in knowing if any user accessible acceleration structures are planned for meshes (i.e. KdTree / Octree / BSP Tree) which could be queried directly for ray intersections, occlusion, CSG etc.

From the first glances, it's shaping up to be quite a flexible engine.

SetBrushColour is nicer, but as seems to be the concensus, documentation readability is priority, so either make it BrushSetColour or ensure the standard docs keep all the brush commands together.

I like the idea of having what your altering first with BrushCreate, BrushColor, etc.. I think that it will help keep code cleaner and help group commands together.

I agree with those going for the brushcreate brushcolor etc... I always group my functions together using this format. It's a more logical approach and makes for much cleaner code imo.

I believe Lua is an optional extra and that you won't have to use it if you don't want to, like oop.

I prefer the CreateBrush syntax, using the BrushCreate syntax may be more logical in an overall design sense but from a user point-of-view CreateBrush is more meaningful.

Again, I have to vote for the brushcreate brushcolor style of syntax (if there' any way of having an influence).

Otherwise I end up wrapping functions....

Funtion BrushCreate(blah)
CreateBrush(blah)
End Function

--- so I can keep them grouped together.

None of us are going to totally agree about how we want commands to look, we're all subjective. Also sometimes it's more natural to say brush first than second, or vice versa. e.g. BrushTexture/BrushColor versus NewBrush/DeleteBrush. If you want the docs to show all the brush stuff together then the docs should be grouped and oraganized as such.

Some days ago Mark Sibly asked about what we are using for content creation. It would be nice to know IF and WHAT decision/conclusion Mark has taken.
And this is of course related to the 'new brush' system he created.
At this point is quite clear that the new brush system and 'managed(?) shaders' require some work in any pipeline for importing/exporting 3d model.
I think this is something important to know.

About the syntax/name convention: even if this is not a rilevant point, for people coming from Blitz3d the 'old syntax' is - of course - a benefit. For other languages (as Max3d will be a 3dlib-engine for C/C++ and others) I dont' know what is the 'best readable/writable' solution.

Go ahead!

ps: urrah! we have an official name Max3d- we need an official logo!!!

BrushCreate is a half-hearted attempt at OO. The procedural API should follow procedural norms.

Therefore I think the API should be CreateBrush and Brush.Create. ;-)

A properly organised, searchable set of documentation would mean that the naming convention ultimately doesn't matter.

It's also easier to port old code. Ordering the docs by category is the logical choice anyway, even if using the other method (you could have other commands falling in the same category but which are not directly related to a set, i.e. it would be silly to have all math related commands starting with "Math", such as MathSin() instead of Sin(), or every network command preceded by "Directplay"... tidier but longer to write for a basic language, which should also have more resemblance to english).

I use a modified version of the help in B3D myself where all the categories are expanded, and it is surely much more easy to search than max's help. :) (for Max as well it would help to have the command reference with all the official modules and their commands as an expanded list on the left)

However I usually write my libraries with the Category_Instruction structure (also to differentiate my commands from the main ones), so I'm used to it either way.

For the naming convention, I'd like to see 'verb' 'noun' to set and 'noun' 'verb' to get, just as you'd use in plain english.

To set attributes:
ColorBrush
TextureBrush
...ETC...

To get atributes:
BrushColor
BrushTexture
...ETC...

This seems logical and natural to me, but I'd be just as happy with SetBrushxxx and GetBrushxxx.


Also, if a language uses a logical convention which is strictly adhered to, documentation is less crucial as the syntax of many commands becomes obvious.

When I was first learning B3D, commands like NameEntity and EntityName were easy to remember but I'd always type TextureEntity instead of EntityTexture.

Much more natural to have:
GetBrushColor
SetBrushColor

Yan, the trouble with that system is a) I don't understand it :) and b) not everyone is a native english speaker and would struggle :)

I think createbrush, setbrush, getbrush, destroybrush etc will do fine. At the end of the day whatever way you impliment it, if anyone wants to do it the other way aound there is nothing stopping them wrapping it up and reversing the names.

You don't understand english? ;o)

As they would with any language based on english, surely?


The most important part of my post was...B3D didn't do this and made things more difficult to memorise than it needed to, as illustrated above.

I'd vote for the CreateBrush / Brush.Create versions over Brush<everything>

Quite happy with this new thing.

let me know if you need a 3D guy with 3dsmax to test it (rob cummings here) and email is hippocoder@... !

so if reading this and need an ex industry artist to test stuff with max/shaders gimmie a bell! got free time now.

I totally agree


I would assume Max3D will mainly be for basic languages, blitzmax b3d & blitzplus, so it should definitely be SetBrushxxx and GetBrushxx, as that has been for quite some time with blitzmax already.

At the end of the day i just want to be able to do blitz-style programming to make 3Dgames using max, for release on linux, Mac (when i can afford one:) and of course the obligatory windows.
Im not too fussed about how i do this, weather the command is setbrushcolor or the oopy brush.setcolor i really dont care, ill just adapt. As for LUA, no idea what it does but if you think it will be useful then great, more the better.

As long as theres a good searchable reference, is Xplatform, 'feels' loosely b3d-ish and "does 3d" at least as good as b3d i will be totaly happy :)

Concerning the LUA implementation, I look at it this way; if the engine's script language enables increased speeds for full access to the commandset, I think it's excellent news.

I found this LUA doc, to whom it may concern:
http://www.lua.org/manual/5.1/manual.html#2

And this impressive benchmark :P
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=gpp

:O I think the choice for LUA is absolutely justified and wise.

There is also this JiT version. I wonder if that was considered as an option?
http://luajit.org/

JIT would be faster than interpreted I'd think.

I would just prefer sticking to one single language for sourcecode and scripts, even if LUA is easy to learn.

I found this LUA JiT 2008 roadmap rather wild:
http://lua-users.org/lists/lua-l/2008-02/msg00051.html

Loving these weekly updates. Now that's some good communication with the community!

excellent, I like the idea of the mega stuffs :)

Swizzels thats lovely can i have some Bangs with that plz.

That would be fun.

CreateSwizzle()
CreateBang()

Hehe:)

Thanks Danman. I agree.
Really I just want new version of B3D with essentially the same syntax and ease of use.
But that may not be what Mark's about.

One more vote for CreateBrush.
I was leaning the other way but I think Mark Tiffany is right. BrushCreate is a bit like a half-hearted OO.

I think if it is named in all sections like

TerrainGetHeight
TerrainLoad

BrushLoad
BrushGetColor

and so on, it is easier to find in helpfile, but then no exceptions like
CreateWindow then also WindowCreate.

or do something like this:

Brush mybrush1

Color $FF5500
Texture tex
....
End Brush

and

BrushLoad mybrush1

Color $FF5500
Texture tex
....
End Brush

and

BrushCreate mybrush1

Color $FF5500
Texture tex
....
End Brush

and additionally

CreateBrush mybrush1
LoadBrush mybrush1, "Brush.bsh"
SaveBrush mybrush1, "Brush.bsh"
BrushColor mybrush1, $FF5500
BrushTexture mybrush1, tex
......

I like the sound of what marks doing whatever way round the "createbrush" "brushcreate" are. But from a pure docs perspective brushcreate seams like it would be better.

I think an upgraded brush system is great, i dont want to worry about shaders.

As for the physics engine its great! i use jv_ode and im sure it will be a case of if you dont want it done use it.

I would like to know if anything is being done towards making this engine fast, its fair enough being shadertastic and physics enabled but if like b3d when you use more than a few animated meshes the thing grinds to a halt.

WILL THIS ENGINE HAVE HARDWARE SKINNING?

WILL THE ENGINE HAVE ANY INBUILT OPTIMISATION OPTIONS LIKE LOD? (just an example)

thanks for the updates mark. i think you have made the right choice. with how to take things forward.

Pete

Why not just do both? It would seem to please everybody, and how long would it take to create a simple find/replace macro for those who want to convert code ;)

What exactly is a scripting language?

What would the advantage be to using Lua over the language that Max3D is in?

And, while we're all making requests, Mark: more file options would be nice. Not just creating and deleting... renaming, for instance.

And finally, like Pete, I:

-don't care whether it's "CreateAwesomeGame" or "AwesomeGameCreate," but am leaning towards the latter for clarity and ease in the docs.
-am more concerned with the engine being fast than with having fancy built-in specular lensflares and the like.
-definitely appreciate the updates and think Mark is heading down the right path (finally)!

Let's see what Wikipedia says: http://en.wikipedia.org/wiki/Scripting_language


Lua is the fastest most popular scripting language out there, and it is free. There is even a Just in Time version of LUA for blazingly fast bytecode execution (correct me if I'm wrong about this).

Consult this list of Lua projects for an idea of how much people are using Lua: http://www.lua.org/uses.html

Wiki: http://en.wikipedia.org/wiki/Lua_(programming_language)

I vote for SetBrush - I always use this convention (in c++ I always name my methods things like Baddie.SetColour() / Baddie.GetColour() ... ) It immediately indicates whether it's a 'to' or 'from' method (sorry, just my made-up terms!)

Lua's a great idea, I'm definitely down (although wouldn't it be nice if you could also have direct access to Blitz's commands / your variables within an intermediate mode.) It would be like the days of AMOS (sorry to bring up one of Mark's ex-'rivals' - I was an AMOS programmer back in the day - experimented with Blitz, but found it too hard at the time, haha.) Anyway, just a pipedream, I'd be happy with Lua.

I'm hoping for a language where you can say 'SetShadows STENCIL_SHADOWS' or whatever and have the shaders acknowledge it, instead of needing to customise certain shaders to get involved with the shadow system, ala Ogre (at least that's my understanding from my limited experience of Ogre shaders.) You can simply say 'SetNormalMap my_entity,"my_map.png"' and the shader would be modified to include the normal map / specular map or whatever.

Either way, Mark's got my hopes up again now, having defected to C++ / Ogre, and I hope he delivers! Go Mark!