Roadmap or ETA on things to come?

[Andy Gilbert]

Hi, Im sure it always seems like someone is asking for more but...

 

This is genuinely the 3rd time ive come back to Leadwerks 3.0 with an idea that ive had to drop due to leadwerks 3.0 not having the features. When i say drop, there is probably "ways" to do what i want but it would mean alot of hassle and work as apposed to having the toolset ready. This time is was a game for iOS but was based outside. So initial issue was terrain, i played with external terrain editors got something that looked "ok", but having to import as a model and use a texture which is limited by size it wasnt satisfactory so i started to lose hope, but the final straw was was when i imported some simple plant models with alpha maps to find shadowmaps project shadows of the whole model (not the alpha map).

 

Now..im not ranting about the specific features above, im just wondering about when features that got mentioned when Leadwerks 3.0 was released will actually get round to being implimented? Its been a while now since release and the Editor still has no boolean operations, just basic shapes to work with?

 

Yet when i come on here i see pushing for linux, OUYA, steam ETC which are all great things, but i cant help feel things are getting forgotten about and "Leadwerks" is running ahead of its self again... Im sure this isnt the case though but when you read...50% reached in less than one week; Work on Leadwerks for Linux begins... Just makes wonder about the basic features still on the waiting list? I dont remember linux being on the phase 1 of the initial roadmap?

 

Anyway, basically this came about because i belive from a quick search i did, the "roadmap" has dissapeared. So just wondering what is expected to come and when, as i feel im still waiting for the features that were spoken about when i purchased Leadwerks 3.0.

 

Thanks

Andy

[Josh]

I'm not writing the Linux implementation. This works best when I stick to the core editor and engine, and farm out the auxiliary components. I attended the OUYA game jam last weekend because I told my friend six months ago I would start participating in his events. I've seen enough that I know it works, so if the stretch goal is met, I'm handing that code off to my Android guy. The crowdfunding model is great because it pays for itself in advance, and allows me to add more value to the engine without taking my time.

 

The next stage of development is terrain and the OpenGL 4 renderer. Terrain, of course, is to be included in version 3.0. I do not have an ETA on that because it involves a "virtual megatexture" technique that is experimental. This is designed to get around the texture layer limitation a lot of people wanted lifted in Leadwerks 2.

 

Another important thing to do is make sure the editor is working completely correctly over the next six months. I am releasing a patch today that resolves several recent bug reports.

 

To be clear, there is no "waiting list" for features. The only additional feature I have promised in version 3.0 is the inclusion of terrain, which was omitted from the initial release in order to get it out sooner. The features you think are most important are not necessarily what other people think are most important. There are many features and enhancements I can implement, but their order of implementation is determined by what I think benefits the most people the soonest.

 

If the OUYA stretch goal is met, I will be adding another goal. I estimate these by taking the cost I think it will take to develop and support something, and then multiplying that by 1.5. It may appear that those extra things are off-track, but remember they take very little of my time, and we only have a temporary window within which we can use the Kickstarter campaign to raise additional revenue. So it makes sense to add those goals now. As long as they pay for themselves, it's not a problem. The money basically just passes through my hands to other local developers, and I only have to describe what the implementation should do.

 

Leadwerks 3.1 is scheduled for release before Christmas 2013.

[Andy Gilbert]

Hi thaks for reply Josh, appriciate it and is somewhat reassuring. But....

 

Leadwerks 3.1 is scheduled for release before Christmas 2013.

 

What is Leadwerks 3.1? What is planned and what will we be getting? At the moment 3.1 could be the current one with bug fixes as theres nothing to look at? Unless i just cant find it?

 

Andy

[Josh]

Leadwerks 3.1 adds an OpenGL 4 renderer. If the kickstarter campaign is successful, Linux support will be added as well.

 

We have been pivoting to find the best area to focus on immediately, but it looks like we have found a good path that plays to our strengths as a PC developer.

[josk]

Will Linux support be included with 3.1 or an upgrade like the Android/ios?

[Josh]

If Linux support is added, it will be treated as part of the PC/Mac package. The Kickstarter campaign pays for the development of this in advance, and tells me whether it's worth supporting at all.

[Roland]

I have been following this at a distance for a while to see where it goes. The direction has been a bit 'floating' as I have seen it. Going back to Windows/Mac/Linux PC is a good thing in my humble opinion and a 3.1 with high end rendering and a good terrain sound promising. So + for that.

[josk]

Some good info in this post. There might have been a few ups and downs but everythings starting to fall into place. Looking good and am looking forward to 3.1.

[Pancakes]

How much for 3.1? It's absolutely essential to me.

[Josh]

So cheap you will be able to afford it, Pancakes. I'm testing the patch right now that knocks out the important 3.0 bugs, BTW.

 

I know we've been putting a lot of different ideas out there, but without that we wouldn't have discovered the strength of the Linux demand, and we wouldn't have the top-performing software title in Steam. These things are important for the long-term strategy of the company. One of the reasons I started Leadwerks 3 was because I knew making a game engine just for Windows alone would never be very successful.

[MikeClarke]

So cheap you will be able to afford it, Pancakes.

 

Im saving that quote

[AggrorJorn]

2.3 was about 30$ I believe. Even so, I bet it is worth it.

[gamecreator]

In addition to TPF (the Pancake factor), it also depends on what 3.1 will include. Considering the list of possible additions shown before, I assume it won't be just the renderer. Can you share what you're planning on including in 3.1 before Christmas, Josh?

[YouGroove]

I'm mainly interested in PC and Android casual or simple games.

 

I think bug correction, physics working good, shader working good , editor working well (auto refrehs problems etc ..) is very important more than upcoming features.

I would say , better take the time to refine actual LE3 even if it should delay terrain, renderer and other new coming features for one or two months.

 

BSP requirements : Will they come ?

1 ) Booleans

for people working BSP, booleans are incredibly missing , specially substract (union allows to create new complex brushes also)

I would say, we need Booleans to have a better BSP system, actually it is really good , but too basic without Booleans.

.2) Visual BSP UV mapping

i suggered possibility to do like Blender : UV map editing for BSP : you select some BSP stuff , and open visual UV editor (move vertices, scale, align, rotate)

3 ) BSP optimisation :

Like Blender, some button to Auto-Weld vertices at same position (standard in BSP systems), this way you can decrease by 2,3,4 or more the numbe rof vertices : rotating 1000 is faster in CPU than rotating 4000.

[MikeClarke]

Visual BSP UV Mapping just complicated a simple system, maybe a simple "drag and drop" (wireframe of face) or hold a key and use arrows to position but the simple drag onto brush is v.fast

 

Booleans again doesn't bother me so much, if you can move verts like the old quake editor then you dont need to cut holes to get good edges etc.

[YouGroove]

well if you use big textures like 4096, and you have lot of textures inside that one (one texture object : memory optimisation, one file for bettertime loading , UV visual mapping is needed if you go BSP).

So i can conclude in that case : avoid BSP go modeler and models

 

Booleans, if you really use BSP this is super needed :

make windows , doors holes on building, with substract supress some model region (broken wall, remove half of some BSP stuff etc ...)

Moving vertice , by vertice is the old way, lot more slow and good if you stay with simple geometry like cubes.

If you get on more complicated :

Union of cylinder shapes and cube as one piece , or other stuff, Union will glue thses as one BSP piece only.

We are in 2013, forget Quake and old workflow

 

Well i will see, but perhaps it is better to let down BSP and go models only from now.

[MikeClarke]

Re the uv texture for bsp like I said a visual render but not an unwrap like a modelling program otherwise you may as well use a modelling program since they have more features than the csg editor anyway. For example Display the texture, then show the selected faces and you just drag them to the position you want on the texture. As opposed to unwrapping it - just 1 face at a time.

 

Moving vertice is the old way, its tried & tested. I actually works great I wish I could find some decent samples from my old work but I don't tend to keep it. We could use cubes to create church arches that are far more complex than the current art tool would allow, or that using a sphere boolean would create. By taking time. The vertice move situation comes for adding finer details to a map, so it should be "slow" cos its precise.

 

If you google "call of duty oraco chelm poland" and check the images, that was a map made by Oraco (later got hired by them) it took about 2-3weeks using csg, not boolean but moving vert's. I've yet to see any modern tools creating maps as fast to that quality, especially consider he did it around uni work & classes.I think it was around 40hrs including concept art.

[Wilds]

I am also missing the boolean operations for CSG.

[YouGroove]

MikeClarke :

Perhaps you don't have used enought modelers

Take a cube , Substract a cylinder at bottom to ahve some quick Arch.

And there are tools , without them you'll put hours to do simple stuff moving vertex : Lathe tools, deformation tools etc ...

 

Modelers are far away in terms of modeling and UV than BSP.

Some AAA games have levels made on Maya, BSP don't exists, caus they need to go fast.

 

If i make a simple game, casual , yes BSP, if i target more complex like 3D Tiles, it will be models caus modeler is total freedom and more tools , faster ones.

 

I don't try to cinvince you, just showed you how fast you go with modeler tools.

Anyway if you are BSP fan and stand in love with old ways, i can understand it

[MikeClarke]

I don't argue against the use of modelling tools, i support that as well I think their needs to be a compromise between models & csg. For that reason I don't think the csg editor should become a modelling tool but a csg tool entirely. Otherwise you may just use all modelling tools. Moving verts just takes csg to a new level of accuracy. + Saves programmers learning extra software.

[YouGroove]

Well even simple stuff as diplicate stairs ( rectangle cube), the BSP UV was changed and moved from how i changed UV on first stair block, and that was bad caus i just needed the exact copy.

Solution, make unique texture per object and let down one big texture containing sveral tiling ones.

Josh told in bug report that's how BPS system and UV works.

 

 

Well what matters is whta you will do could it be BSP or models

 

Ok, so i will have to keep all way of working and stuff simple (no booleans) if i go BSP.

[Thomas]

2.3 was about 30$ I believe. Even so, I bet it is worth it.

 

It was $50

[risecreature]

What about shadows casting on .fbx models and dynamic lighting ? Will it be included in Leadwerks 3.1 ?

[Josh]

I'm implementing an OpenGL 4 renderer that uses dynamic lighting in 3.1.