Searching for the right engine.

[EagleEye]

The latter.

 

That's what I figured... okay then, that's cool...

 

So I can make like, a single continent in the editor, and stitch them together as multiple continents, with a large water plane as the sea, and a large floor as the "bottom of the ocean" type of thing...

 

What about if I have 2 landscapes side by side and want them to flow together? Is there a way to "fix the seams" between them?

 

That's what I figured... okay then, that's cool...

 

So I can make like, a single continent in the editor, and stitch them together as multiple continents, with a large water plane as the sea, and a large floor as the "bottom of the ocean" type of thing...

 

What about if I have 2 landscapes side by side and want them to flow together? Is there a way to "fix the seams" between them?

 

OOPS! Disregard all that... I had not yet seen page 2. :-p

[Rekindled Phoenix]

I don't personally know of anyone currently using VB.Net

*raises hand*

 

Some game developing communities do have language elitists. I'm glad Leadwerks isn't one of them.

 

I seem to be the only other VB.Net programmer using the C# Wrapper. This community hasn't shown any negativity towards my choice of language. A .Net API gets compiled all the same to me.

 

Glad to see another VB.Net developer on board.

[ZeroByte]

I would prefer to use vb.net also, but as mentioned, it's not officially supported yet, and i haven't been able to get the Custom Buffer working

 

with vb.net since LE 2.12. So i've been using c/c++, thank's to the easy to understand tutorials, and helpful community. LE makes using c/c++ easier than

 

other engines i've tried, but i still struggle with it's syntax when i run into problem's.

[Josh]

So I can make like, a single continent in the editor, and stitch them together as multiple continents, with a large water plane as the sea, and a large floor as the "bottom of the ocean" type of thing...

It might be possible, but you will run into so many problems. If a 4096x4096 heightmap is too small for your purposes, you should use another engine.

[Rick]

I think it would be easier to make all your landscape segments in a different program as a 2D image and then make a program that stitches these images together and then create a customer landscape class that reads 1 image file and makes a plane to mimic that image as the terrain. Trying to get the editor to do this would be a mess. The downside to this is that you lose editing the terrain in the editor. You could probably add that functionality but it could end up being messy.

 

I think there are generic terrain editing programs out there that allow you to edit in real-time and can output an image file that LE can then read in and use. You would have to create our own LE custom reader for this since you would want to read in multiple terrain files and create planes based off these.

[Josh]

You'll also lose the engine's vegetation system if you make your own terrain.

[Rick]

Very true. I assume a person could write their own using what LE provides?

 

In my mind I'm thinking this custom terrain system would be more for someone wanting to create some sort of MMO that allows them to load segments of their world as they go. Most MMO's aren't heavily populated with vegetation tot he degree that the current system does it, so it skipped my mind.

[Josh]

The vegetation system is so highly optimized. It took a year just to think of how to do it, then it had to be written twice to get it right. The memory consumption alone would prevent you from matching this with mesh entities.

 

If you don't need as dense of vegetation, then you might reasonably be able to implement your own system.

[Rick]

The memory consumption alone would prevent you from matching this with mesh entities.

 

I agree, but I assume one could load once and draw many times to reduce the memory footprint. For us to do it, we would most likely have to get into OpenGL code. Not trying to over simplify it because I'm sure it's a huge pain to get right.

[Josh]

Yes, that's how I do it. Each instance consumes 64 bytes of memory, and I use an array of matrices for drawing.

[Rick]

What are you all storing off? Just the position or other info?

[Josh]

Just the 4x4 matrix, and instance center and radius for culling.

 

Newton's proxy system is pretty good, but I am going to try to convince Julio to use an array of matrices, so the physics can just use the same data.

[EagleEye]

It might be possible, but you will run into so many problems. If a 4096x4096 heightmap is too small for your purposes, you should use another engine.

 

I guess my question then would be... what sort of height map granularity should I be going for then?

 

If it's 1px per meter, that's only 4.1km^2 for the entire world... which is pretty tiny.

 

However, if I can get away with like, a 1px per 10 meters, that's 41km^2... but that really depends on if there's good smoothing between heightfield pixels or not.

 

Even then, I'd probably want to get at least up to the 100km^2 range, meaning a 25:1 ratio... 25meters between pixels on the heightfield, at ground level?

 

Surely there's another way to approach large landscapes in this engine?

[Josh]

This is the only thing I know of that can do what you want:

http://www.codemasters.com/games/?gameid=2846

[EagleEye]

And just as an aside... home-grown solutions are what I'm trying to get away from... so rolling my own landscape system would pretty much invalidate using the editor, which is what I want to be able to use in the first place.

[EagleEye]

well, it's looking like this engine isn't the right one for me then... straight out of the developer's mouth.

[Canardia]

Any engine which can do it? 5 billion dollar engines don't count

[EagleEye]

Any engine which can do it? 5 billion dollar engines don't count

 

I'm looking in to http://game-engine.visual3d.net/

[Pancakes]

Yeah if they release that particular engine with the features that they planned on within a certain span of time, it will be a extremely big deal. However with the delays, it's going to give literally everyone else a chance to catch up with them. I own a license to Visual3d.Net. It was a difficult decision to leave Visual3d for Leadwerks, but not so difficult to stay here. Those are good people and they have stated that their niche is large landscapes so I think you might be right, Visual3d.Net is the right engine for you. Their water and sky is amazing. However their interior lighting optimization is non existent.

 

So for me it came down to amazing water and sky and large landscapes of Visual3d.net, vs the amazing rendering and lighting of leadwerks. I like them both.

 

If only we could smush them together and form one giga engine like Voltron.

 

I mean now that I think of it. Since Josh is looking for investors anyway. What if Leadwerks and Visual3d.Net just combined their code into one somehow. Then Leadwerks would inherit the infinite landscapes, advanced water and sky, while Visual3d.Net would inherit deferred rendering Lua scripting and a really nice API. Hmmm. I wonder what Josh thinks about that. The guys at V3d.net have spent years on their infinite landscapes already and are almost ready to push it out I think. Yet they don't have any interior lighting scheme at all, which Leadwerks is a genius at doing.

 

Oh well it's best for me to stay out of this sort of business. But an interesting musing anyway.