Deciding on an Engine...

[knocks]

Leadwerks graphics are stunning, and the community is very helpful, im not a programmer and was attracted by the addition of lua. However i am finding it hard to make the jump from T3D, I find LE's pipeline and editor very cumbersome and difficult to work with efficiently.

[Marcus]

What one is supposed to be better in those 2 images? I find the left one looks better

 

Programmer's are hilarious.

 

The one on the right looks realistic, while the one on the left has flat lighting.

[Niosop]

The one on the left is being lit by primarily by ambient light, the one on the right is being lit by ambient light and the yellowish light being reflected off the sand.

[Rick]

Programmer's are hilarious.

 

The one on the right looks realistic, while the one on the left has flat lighting.

 

 

Really? The detail gets washed out on the right though. For example you can hardly see the steps on that back plate on the right. Also the muscles on the left arm is more defined on the left where again it's washed out on the right. The only place it looks more realistic on the right is where the feet meet the terrain I think.

 

This is why I'm not an artist though. I can't see why making things brighter and washed out makes it look more realistic. I also can't stand the blurring effect every new game seems to have these days. It hurts my eyes because nothing is ever sharp and in focus even at short distances.

[tcmodder]

Well your thinking well im asking about witch engine is best on an engine cpmpanys forum so there gonna say LE is the best.But take my word i have been through all kinds of trials and demos and decided on hundreds of engines at one time.But once i got the evaluation kit to work on my computer from LE i knew it was for me.It is amazing.Also the tutorials that come with this forum and other forums has helped me a bunch in learning code in only 30 days lol(my trial).So LE is for you.It works great and i would recommend it for anyone.

[Josh]

Really? The detail gets washed out on the right though. For example you can hardly see the steps on that back plate on the right. Also the muscles on the left arm is more defined on the left where again it's washed out on the right. The only place it looks more realistic on the right is where the feet meet the terrain I think.

The idea is the light bounces off directly lit spots and illuminate other areas indirectly. Most real-time GI attempts use a bunch of point lights in a grid to try to simulate this effect.

[Canardia]

No offense Lumooja, but your chart is one of the most absurd things I have ever seen. You miss critical features and you don't give proper weight to other features.

There is also a weight info, but I still need to add the weighted score column.

[Rick]

The idea is the light bounces off directly lit spots and illuminate other areas indirectly. Most real-time GI attempts use a bunch of point lights in a grid to try to simulate this effect.

 

Ah ok. Just kind of stinks that it has to wash some detail out.

[Canardia]

Ah ok. Just kind of stinks that it has to wash some detail out.

If you look at the cloack of the right side picture, it has more detail than on the left side pic. It's just the ambient light setting which is set too bright.

 

A fully implemented GI, will also cast shadows of the light bounces, so there will be always more details than without GI.

[carlb]

lol rick

i will say on a very bright day most colour get washed out(when sun glasses are off)

so what they showing is very true

 

but yes i like the left pic more then right, but at the end you decide how your game looks and what details you want

[L B]

The picture is exaggerated in this case, only to show what GI actually is.

Although yes, the one on the right is more realistic.

[Michael Betke]

You guys are always ending up discussing LE vs Torque vs Unity3d.

 

These guys are very fast progressing with their engine and I think from an artists point of view (this what I can only judge without having the tools at hand) they are most promising: http://www.youtube.com/user/NeutronEngine

 

So I would like to ask a question to bring this discussion a bit furhter:

 

What should Josh develope to gain or hold a unique selling point compared to the other engines you guys always mentioning?

[Canardia]

• Visual quality must improve:
  
  • Shadows must be sharp when near the object, and blur to distance of object
    
  • Shadows must start exactly at the object, and not have some gaps
    

  [*]Visual limits must be removed

  • Shadows of objects further than 500 units away from camera must be still visible
    

  [*]Visual speed must improve

  • When using camera with over 500 units range, the FPS goes down remarkably in big outdoor scenes
    
  • Fullscreen mode at FullHD resolution (1920x1080) is too slow with heavier scenes
    

Note: I might also upgrade my GeForce 8800 GTS 640MB to overcome the mentioned speed issues

[Niosop]

I don't think he needs a unique selling point. Right now the visual quality of the engine IS his unique selling point. What he needs to do is stop looking for unique features and add in stuff that the other engines have that improve workflow and the asset pipeline.

 

Things to take from Unity:

 

* Visual in-editor physics and joint editing w/ constraint visualization. Or better yet, something like the UDK's PHAT editor. Having realtime physics in the editor is great but creating the physics assets is still a big pain.

 

* Clone their asset importing pipeline. You can't beat dragging an asset into the editor and having it be automatically converted and just double clicking the asset to automatically launch the associated editor for that asset, make changes, hit save and have it be re-imported into the engine. It's a MAJOR time saver.

 

* Prefab support - another HUGE thing we're missing.

 

* Multiple scripts per object - it's nice to encapsulate code into small snippets, then just add the snippets that are desired to an object. Much easier than opening the lua file for that object and adding in includes and function calls to include the code you want. And cleaner than making a thingoid that you have to drag into your scene and link to your objects.

 

* More than 5 terrain textures.

 

Things to take from the UDK:

 

* A static lighting baking option like T3D's PureLight or the UDK's Lightmass. Yes it's expensive in terms of additional texture memory required. But it can make a big difference when used judiciously and the fact that it's easily misused isn't a reason for not offering it at all.

 

* Node based material editor. The shader system in LE is already based on snippets that are conditionally included. This could be taken to the next level so that each material can have it's own unique shader that is built at startup AND REBUILT WHEN IT CHANGES. It's a big time killer to close the editor, edit the shader, start the editor, check the results, repeat. Josh has already said he'd like to implement this.

 

 

Many of these aren't engine issues at all and could be implemented w/ the current LE API. But they would require that we totally rewrite the editor from scratch to add them. Making a plugin system for the editor that would allow you to add your own menu items, popup windows, receive all events from the main editor process to act upon, send commands back to the editor, etc would allow us to write some of these ourselves and take some of the load off Josh.

 

Anyways, I think I've mentioned all of these before, but I think it's pretty important that these are addressed to stay competitive.

 

Just my $0.02.

[VicToMeyeZR]

Don't forget serialized instanced entities.. Or whatever the "technical" term is for it. This is a HUGE needed, as currently trying to make any customizable RPG with different characters isn't possible without having a different mesh for each and every character. Yes this will drop the bone limit to 64, but the trade off is well worth it.

 

Also source owners, could help a lot in these areas if Josh lets them. They already have the source...( I currently do not know if they do already or not)..

[Niosop]

If we could assign an existing bone weight matrix to a duplicated mesh then we could create our own non-instanced copies of a model. But the API doesn't give us any access to it.

[Canardia]

You can create a new copy of the model and have non-instanced models. You can even do it while loading the scene, so you don't waste disk space. That's something I planned to have in gamelib also.

[carlb]

the only bit that i would like to see is mult water lvl( for sea and diffrent lvl lakes and rivers)

 

as i want to make a dam scene with the three water lvl and a river. then am happy lol

[Pixel Perfect]

I've said this before and I think its worth repeating. Most Indie game engine developers would go out of business if they only sold their engine SDKs to people who were actually capable of producing games and taking them to the marketplace. Obviously the intension is to have people do just that but in reality it's not their main customer base. The main customer base is all the people who dream of making a game and have sufficient liquid assets to purchase a nice looking engine but in reality have little to no idea of how much work is involved and will end up playing at it. There is nothing wrong in that, but it does make a big difference to the priority that a developer puts on his development list; which may seem at odds with the wishes of the smaller percentage of genuine game developers. Basically, a candle that burns brightly will attract more attention and that represents survival to a small developer. So eye candy is important for raw sales; as is perceived ease of use. Integrated and sophisticated toolsets are expensive to develop and small fixes and improvements to things that are not going to be obvious to a new buyer do not generate new income of as themselves.

 

It's a cynical view I know but one which I believe is part reality if the developer has not reached a certain level of financial security. I believe Marcus was quite correct when he inferred a one man business cannot realistically compete on the same level as some of the bigger outfits.

 

I've stuck with Leadwerks primarily because I think the API is so well written that it’s a pleasure to code with and because whilst I'm going through the learning curve of 'making a game' it's as good a vehicle as any. I hope new people keep buying the engine and give Josh continued stability so that eventually some of the much needed improvements and toolsets come to be. I do have great faith in Josh's ability and perception and hope that by the time I am nearing the end of my exercise in building a game engine with LE2 that these issues will have been addressed and we can take advantage of them.

[Rick]

You can even do it while loading the scene, so you don't waste disk space.

 

You would still be wasting disk space. If you are making a copy of a model on disk then you are basically copying and pasting that model many times over and then loading the newly pasted model. Which means while the game is running you are wasting disk space. Even in the case the game crashes and the code that deletes all these copied models doesn't get a chance to run, you are wasting disk space. Sure at load you can first clear out a certain directory where you placed all these to compensate for the game crashing and not being able to clean up all those temp models, but that's still a very horrible solution. Do you know of a game that does this? It's just a bad solution to the problem.

 

Plus when dealing with something like an MMO, you don't know how many copies you will need because it would all depend on how many players are on screen at one time at any given moment in the game. You wouldn't want to undershoot that number because doing this on the fly would cause a 2-3 second lag in your game, even if you do the copying and pasting in another thread, you have to load this new instance and since LE doesn't support threading, that load of a new instance takes 2-3 seconds and would freeze your game.

 

Given this limitation I think the best approach to date is the shader method Nio made. This is because when new players enter your screen loading them is instant with no delay because you are loading the model that is already loaded and only making another instance of it. Then you select which index to use. This of course has other limitations in the amount of combinations you can have (if your texture sizes aren't insanely large that is), but at least there is no pause in your game when you need to load a new character.

[VicToMeyeZR]

oooo... only 3-4 post in this thread

[Josh]

They were posts asking why the thread was moved. Please stay on topic.

[VicToMeyeZR]

@OP... For $200USD, you won't find a better one. Its that simple. You can try to compare to others it you want, but you have to weight the cost also, not just the eye candy.

[Alberto]

I think the biggest thing LE has for it is the easy API. It's the easiest API I've ever used. As a programmer even if the graphics quality wasn't as good as it is, I'd still use it simply because the API is so easy compared to the others I've used. Entity programming is the only way to go and LE implements it very well.

 

I am also intersted in Leadwerks for the same reason

I own Unity3D,excellent engine out of question but I never get used to "components", I still prefer Entity programming

[Canardia]

I agree 100%, I have also many engines, but I don't use them because they don't have entity programming. The only exception is Blitz3D which I also have, but it doesn't have shadows and physics, so I use LE instead.

 

I even asked in the forum of another pretty decent engine if it could be used in entity way, but they said it would require major changes. Which makes me wonder how on earth can something even work decently without entity programming. It must be complete spaghetti code and needing rocket science to even turn an entity (using quaternion maths)

 

One of the biggest benefits of entity programming is that you don't need mathematics at all. You only use vectors and pivots and tell how to turn, move, scale, parent, etc... them.