what do you want see in leadwerks 3.0

[Josh]

I would like to see more control over sound entities (including out of the box parent functions, sound duration, utils, etc) and emitters/particles. For instance: I'd like to set individual particle color without having to create multiple emitters.

Since all entities can have a script attached, it is easy to make script functions for particle emitter entities, where you control each particle's properties when it is emitted.

[MasteR]

I would like to see the TVec data structures and Vec functions perhaps renamed to include an 'f' on the end.

 

e.g.

TVec2f

TVec3f

 

Vec2f

Vec3f

 

I also think the font load function should accept an image filename as its argument including the '.dds' (or whatever format is chosen)

[Marcus]

Undo.

[Canardia]

Occlusion culling.

[Ending Credits]

I'm sure it's been mentioned before but proper multithreading support.

[niv3k]

i wanna see leadwerks 3 games sold world wide.

[Marcus]

i wanna see leadwerks 3 games sold world wide.

 

Which leads me to my next request....

 

Proper unicode support.

[Chiblue]

The ability to reference other objects directly within an script... basically what I would envisage would be 2 new lua variable types. The first would be a "class type", although I guess using a string would work also... but basically the other variable type would provide a pull down that would list all objects in the scene of that specific "class type"... once linked in this way we can then read that key in code and return the reference to the attached entity.

 

For example, this would allow me to have a character model defined within the scene, and link to each slot of that character a weapon object that is in the scene. Another option would be creating waypoints were you can link wapoints and visually see the links, I would guess a simply line connecting them would be ideal, another option here would be creating transporter locations....

 

I would like to add I love the idea of having zones witin the scene, this will be very useful... Day/night cycles would be nice... rivers definitely...

 

How about a new light type that is a point light that we can define the length and width, or even the shape, this would be useful for modelling different light sources...

[Rekindled Phoenix]

Has collision-based particles been mentioned yet?

Realistic smoke...

 

I would also like to see static particles, where they exist eternally.

This would be useful for haze / fog, ground details, creating your own imposters...

[Laurens]

Not really a feature but I would like to see all functions neatly encapsulated in a namespace. My function names sometimes collide with LE functions.

[Marcus]

Not really a feature but I would like to see all functions neatly encapsulated in a namespace. My function names sometimes collide with LE functions.

 

+1

[Michael Betke]

I want to see a Material Editor with customisable UI and integrated shader editor! Do I get it?!

 

Sorry but it's like knowing the lottery numbers of the future hehe.

[Canardia]

Not really a feature but I would like to see all functions neatly encapsulated in a namespace. My function names sometimes collide with LE functions.

How's that possible? Because even LE2 has it's own namespace LE.

Are you sure you put your own functions into your own namespace also?

[Game Producer]

How's that possible? Because even LE2 has it's own namespace LE.

Are you sure you put your own functions into your own namespace also?

+1

 

I also think devs need to have their own namesspace and/or way of naming functions/classes.

 

 

I'm sure it's been mentioned before but proper multithreading support.

 

+1

 

Reasoning:

- http calls to server (for example, when fetching online high score)

[Josh]

All LE3 functions are in an le namespace.

[Game Producer]

By the way, there's more reasons for multithreading:

- fetching online highscore and...

- refreshing master server and..

- joining multiplayer games!

 

It's a pain in the buttocks if game freezes for few seconds when you are "refreshing master server list" or "joining game".

[Rick]

RakNet ftw

 

The way I see it, if you are expecting anything short of buggy network code from LE 3 you are expecting to much. Much like Josh uses a physics library he would be wise to use a tried and proven networking library as well that has all these features in it already, or honestly better yet, we should just use said libraries ourselves

[Josh]

I hope I am able to prove that wrong.

[Laurens]

How's that possible? Because even LE2 has it's own namespace LE.

Are you sure you put your own functions into your own namespace also?

 

I do not remember this being the case when I made this feature request, the 8th of november of last year

[Laurens]

By the way, there's more reasons for multithreading:

- fetching online highscore and...

- refreshing master server and..

- joining multiplayer games!

 

It's a pain in the buttocks if game freezes for few seconds when you are "refreshing master server list" or "joining game".

 

Multithreading +many. I would love to be able to call on Leadwerks from different threads. Since streaming terrain is on the roadmap I suppose you can't get around it anyway.

[Game Producer]

RakNet ftw

 

The way I see it, if you are expecting anything short of buggy network code from LE 3 you are expecting to much. Much like Josh uses a physics library he would be wise to use a tried and proven networking library as well that has all these features in it already, or honestly better yet, we should just use said libraries ourselves

Hmm, so ... if I use RakNet, I can make http calls without freezing the app? How's that possible? o.O

(bear in mind I use Bmax)

[Rick]

Hmm, so ... if I use RakNet, I can make http calls without freezing the app? How's that possible? o.O

(bear in mind I use Bmax)

 

RakNet runs on another thread. You basically poll to see if any data is ready in your main loop, but it doesn't freeze your main loop. It's possible because you aren't doing anything LE specific in the RakNet thread. You are just passing data around. Once you have that data in your main LE thread you can then call LE specific functions.

 

bear in mind I use Bmax

 

I don't know if RakNet works with BMax.

[Josh]

Multithreading +many. I would love to be able to call on Leadwerks from different threads. Since streaming terrain is on the roadmap I suppose you can't get around it anyway.

There is a huge difference between running a single self-contained process on another thread and designing a command set that can just be called in any order at any time. Even if I locked the threads in every single call (which would eliminate any speed gains you might get from multithreading) there's still a ton of errors the user can cause themselves.

[Rick]

maybe callbacks when models are fully loaded from a loading thread and we can copy the data to our main thread which should be faster.

[Rekindled Phoenix]

maybe callbacks when models are fully loaded from a loading thread and we can copy the data to our main thread which should be faster.

Leadwerks.Net already has events that fire when a model is Activated or Updated physically. This may help.

 

There is a huge difference between running a single self-contained process on another thread and designing a command set that can just be called in any order at any time. Even if I locked the threads in every single call (which would eliminate any speed gains you might get from multithreading) there's still a ton of errors the user can cause themselves.

I agree. Josh should not create a separate environment calling thread-locks every frame. This would cause necessary thread-thrashing within the CPUs. Even then, each method call would have to check whether it is the Marshalling thread (main thread), and invoke a request if otherwise.

 

 

When dealing with multi-threaded environments that use graphics rendering code, you must create a separate buffer for which to call upon. This allows you to reference a particular 'state' of the last rendering cycle represents.

 

http://msdn.microsoft.com/en-us/library/dd287191.aspx

In .Net 4 you can use a thread-safe concurrent dictionary which will solve most of the work for you.

(One more feature that makes it easier to use .Net)

 

It would be an amazing feat if Josh recompiled Leadwerks into an optimized multi-threaded environment with object states internally, but that I think is asking too much.