what do you want see in leadwerks 3.0

[macklebee]

thats a lot of "could"s with no actual proof of any benefit at all... much less increase Josh's ability to easily create and modify apps as he can right now with maxgui and its capabilities...

[Rick]

Yep, you are right, it is. Just seems to me that you "could" avoid issues that aren't known now with using the same language for the UI's that the library will be written in. Seems to be what he did with LE up until now with BMax. So really, by mixing languages he might be going into unknown territory.

 

He wasn't comfortable with C++ but he picked it to rewrite LE 3. That's for sure causing some slow down compared to if he kept with BMax to make LE 3, and he seemed OK with that. He seemed open to the idea, so thought I'd bring it up. Just trying to show the other side.

[Josh]

He wasn't comfortable with C++ but he picked it to rewrite LE 3. That's for sure causing some slow down compared to if he kept with BMax to make LE 3, and he seemed OK with that. He seemed open to the idea, so thought I'd bring it up. Just trying to show the other side.

It's always good to look at all sides, even if you don't change your mind. For the engine, there are clear benefits to using C++. I don't think this is the case for the editor.

 

Question1: Will it be possible to convert models, textures like before with tools or everything is going to be in the editor ? Because the actual tools are pretty usefull to make some batch for converting multiple models/ textures.

All converters are still just command-line utilities stored in the "Tools" folder. The editor calls the process and reads back the console output to tell when it's done. This means the converter code is separate, you can add your own converters, and if a converter crashes the whole editor won't crash.

[Marleys Ghost]

Yep, you are right, it is. Just seems to me that you "could" avoid issues that aren't known now with using the same language for the UI's that the library will be written in.

 

 

So what you're saying is there are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we now know we don’t know. But there are also unknown unknowns. These are things we do not know we don’t know, and its all avoidable if he uses C++ for the editor?

[macklebee]

Yep, you are right, it is. Just seems to me that you "could" avoid issues that aren't known now with using the same language for the UI's that the library will be written in. Seems to be what he did with LE up until now with BMax. So really, by mixing languages he might be going into unknown territory.

 

well considering he is still going to support bmax for LE3, much to some people's chagrin I suspect, any of these issues would have to be worked out any ways... because there will be people that will use the c++ lib in bmax as well as the bmax modules.

[Rick]

It's always good to look at all sides, even if you don't change your mind. For the engine, there are clear benefits to using C++. I don't think this is the case for the editor.

 

Yeah, you are right. There are no clear cases for using C++ for the editor that I can think of. I don't have the experience of BMax and mixing languages with it and such. The closest thing I can think of would be if the engine was written in C++ and I used .NET for the editor, one has to do headers and all that stuff, then you risk errors there so if I was in that situation it would seem best to avoid all that junk, but I don't know BMax so not sure how it plays with others.

[Josh]

So what you're saying is there are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we now know we don’t know. But there are also unknown unknowns. These are things we do not know we don’t know, and its all avoidable if he uses C++ for the editor?

hahahaha

 

We know where the bugs are. They are in the areas north, south, east, and west in the code.

 

Since BMX supports just about every data type C++ does, it's not a problem. You can probably even access the C++ fields and methods with BMX.

[Rick]

So what you're saying is there are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we now know we don’t know. But there are also unknown unknowns. These are things we do not know we don’t know, and its all avoidable if he uses C++ for the editor?

 

Basically

 

No, for real though, using the same language for an editor that a library the editor uses, just seems like you can avoid any issues and glue code required with mixing different languages together. That's all I was saying. I understand Josh hasn't used any of these C++ UI's and that he would start out less efficient in them, but there would be no doubt he would get proficient with them. The tools have been proven. They have been used in enterprise applications already. It's not like I'm asking him to test a product that hasn't been proven.

 

http://qt.nokia.com/qt-in-use

[Pancakes]

I'm thinking Rick's main point is, what if Josh becomes preoccupied with some other part of the code and he has to hire someone to complete some parts of the editor. It would be a lot easier to get someone if it was written in non-Blitzmax basically. I think that's his point.

[macklebee]

thats a pointless argument considering Josh has always stated for any upgrade/update that it will be done when it is done...

[AggrorJorn]

Aggror, everything you listed is planned. I also want to be able to record an AVI from the editor by rendering each frame along a camera path, and then combining the frames into a video file.

 

That is good to hear. Something I forgot to add to that list: LOD particles or Distance setting for particles.

[Rick]

That actually wasn't my point Pancakes, but that is for sure a valid one. If he plans on "outsourcing" some of these tools, the professional base for BMax is certainly smaller than for C++.

 

I honestly don't expect Josh to change from using BMax (just wanted to show the other side), but it will be educational to see if there are any big obstacles that come out of using a different language for the UI tools than the core engine is written in.

[omid3098]

store veryex color per instance. (so it needs vertex paint in it's own editor)

Silex like sky and whether system.

powerful material editor to create and modify many kind of shaders. like blender material editor or unreal.

cutescene editor

better terrain tools for sculpting, and texturing.

[L B]

Extrude-able terrain. Or did I mention that already?

[Pancakes]

store veryex color per instance. (so it needs vertex paint in it's own editor)

Silex like sky and whether system.

powerful material editor to create and modify many kind of shaders. like blender material editor or unreal.

cutescene editor

better terrain tools for sculpting, and texturing.

 

or he could just find a way of taking advantage of all of blender's code, I'm not sure if it would be called a plugin or not

 

and yes I know you're tired of me saying that but now would be the perfect time to give it some thought

 

just imagine, cinematics tools, sculpting, ptex, modeling,materials, bullet physics, light mapping, flowgraphs...these things have already been coded inside blender already. The biggest hurdle is the legal research I would guess. This would instantly teleport your editor's funcationality above and beyond all others in existence.

[L B]

It's always good to look at all sides, even if you don't change your mind. For the engine, there are clear benefits to using C++. I don't think this is the case for the editor.

 

 

All converters are still just command-line utilities stored in the "Tools" folder. The editor calls the process and reads back the console output to tell when it's done. This means the converter code is separate, you can add your own converters, and if a converter crashes the whole editor won't crash.

I'm currently writing a byte reader/writer for GMF, along with a C# editable mesh class. This should allow me to make plugins built into Middlewerks for any given file type.

[VicToMeyeZR]

Did anyone bring up the instancing of meshes? Having the ability to have different textures on the same mesh, is a MUST for any engine.

[Josh]

I'm working on the texture class right now, and for that I am using an optional flag to load a unique copy of the texture:

 

LoadTexture( "wall01.dds", MEDIA_UNIQUE )

 

The unique flag will cause the engine to always load an original copy of the file from the disk, instead of creating a copy of an existing item. This same approach can probably be used with shaders, sounds, meshes, etc.

 

However, unique meshes will not be instanced, so you would only want to use this when you need it.

 

The default behavior will be the same as LE2.

[dreamhead]

that would be a nice option to have... would the editor have 4 viewports? or would this be a separate small app that allows you to create the solid then the auto file detection would load it into the assets list?

 

No, you would just have some creation parameters like width/height/depth, and then attach the solid to an entity. The Quake-style editing isn't something I want to get into.

 

WAT!!?? no 4 viewports?ar you kinding me josh ,every artist needs to have a good view of what he is making and certainly at rather complex scene.

it is like if you took ruler from a architect he then can never make a good blueprint.

so please josh reconsider this, it wil have great a inpact for al 3d artists that use your engine

[L B]

I'd like 4 view ports too. I don't see why it would be hard to code. Set the mouse/keyboard input to the viewport last focused (clicked). Have all other viewports just be a camera. When you get in a viewport, you can move the camera with the WASD as usual.

 

But agreed, it's far from being *that* important. Probably more of a gizmo than anything else.

[dreamhead]

I'd like 4 view ports too. I don't see why it would be hard to code. Set the mouse/keyboard input to the viewport last focused (clicked). Have all other viewports just be a camera. When you get in a viewport, you can move the camera with the WASD as usual.

 

But agreed, it's far from being *that* important. Probably more of a gizmo than anything else.

no it really matters how many viewport you have ,it can make or break your lvl depending on your viewports,you can ask every artist the will tell you the same thing

[Alessandro]

Hello,

I red the part related to GUI development, and it is really interesting.

I found a lot of good comments that I already red in other forums (for other applications).

Sometimes I think it could be a good solution even creating a GUI with a really different tool, than let this tool and LE talking via sockets or Inter process communications.

I made it for other programs and it works very well, since the GUI created in this way could act as a "glue" between different programs.

 

A good system to make GUI is using tools live Runtime Revolution (http://www.runrev.com). It is cross platform and contains a lot of components to make great looking and efficient GUIs. I wish to highlight I'm not affiliated with the official RunRev company! :-) This is not a publicity (I say this since that product is not free or open source, but a commercial program).

 

If you need more info about it, please don't hesitate to contact me (I use it since several years and I made many different programs with it).

 

Cheers!

[Pancakes]

Not that I consider myself much of an artist but I thought the grid snap was enough. I've never used multi-viewports not even in blender for just modeling things.

[VicToMeyeZR]

I'm working on the texture class right now, and for that I am using an optional flag to load a unique copy of the texture:

 

LoadTexture( "wall01.dds", MEDIA_UNIQUE )

 

The unique flag will cause the engine to always load an original copy of the file from the disk, instead of creating a copy of an existing item. This same approach can probably be used with shaders, sounds, meshes, etc.

 

However, unique meshes will not be instanced, so you would only want to use this when you need it.

 

The default behavior will be the same as LE2.

 

Thats a bummer. I really thought we were moving to good tech not old tech

[Josh]

What is it that you were expecting different? Doesn't that confirm that you can load unique instances of media files?

 

The design I described also allows you to alter the vertex data of a unique mesh without affecting other instances of the same file.