Help with coding a new max world size.

#1 There is no hardcoded max world size. Visibility range can be adjusted from the LevelInfo object. Terrain size depends upon heightmap dimension and squareSize. MissionArea is an optional trigger-like boundary that can adjusted to a desired size.

Solution files are generated by running the project generator.

#2 Ok well that kind of contradicts everything I have read on the forums about Torque 3d's max world size being 2048^2 and 1024 roughly in height.

I don't want to have to generate a new project every time I make small changes to the code to test it out. Is there an ETA on the Torque front end will be available in the repository ?

#3 No contradiction at all:

• 2048^2 is approximation given default sizes and settings - heightmap size (2048), meters per pixel (1), and squaresize (1)
• 1024 roughly in height corresponds to the the heightscale. No matter if this setting is 256 (the default) or 4096 the number of indvidual 'steps' in a terrain's height from lowest point to highest point cannot be greater than 1024.

Once you initially generate your project using the Toolbox it doesn't have to be regenerated for each change. You are responsible for keeping your IDE up to date in regards to adding/removing new files to the solution.

#4 There is no maximum world size, just like Michael said. You get decreased precision the further away from the origin that you go, but thats not trivial at all to solve which is why few engines have it.

#5 @Michael,
What do you mean by height steps? When I import height maps using a 16 bit single channel png I get 65536 resolution in height. Is the 1024 a floating point number governing position of the player?

Edit:
@Stephan,
Could that be solved by using fixed point numbers? I know I read in fractal projections they get high resolution using fixed point numbers.

#6 I was wrong, it's 2048 for the height range.

Torque TER files store the height as 16-bit values representing a 11.5 fixed point format. The 16 bit values are converted to floating point elevations using the 'fixedToFloat' function declared in 'terrFile.h', which is:

/// Conversion from 11.5 fixed point to floating point.  
inline F32 fixedToFloat( U16 val )  
{  
   return F32(val) * 0.03125f;  
}

Which is to say that each step in the 16-bit values corresponds to a 1/32nd of a metre in floating point altitude.

With the 16 bit values having a possible range of 0...65535, the possible range of floating point altitudes permitted by the above function is 0...2047.96875 metres. Thus, the maximum altitude range (i.e. max - min) is ~2048 metres.

#7 Well either way it will cost me money to get this engine inline with today's modern engines and in a more usable fashion (for what I need it to do). Right now the only thing it has going for it is that it's MIT and has a world and plant editor.

#8 Ok so if i understand this correctly

/// Conversion from 11.5 fixed point to floating point.  
inline F32 fixedToFloat( U16 val )  
{  
   return F32(val) * 0.03125f;  
}

and change it to

/// Conversion from 11.5 fixed point to floating point.  
inline F32 fixedToFloat( U32 val ) or (U64 val) 
{  
   return F32(val) * 0.03125f;  
}

It's been nearly 20 years since I last had to read or write code Guess I need to go out and get a book for a refresher course lol

#9 @Michael,
Ahhh, okay, I was wondering if it was something like that. Thanks for in depth info.

Quote:Well either way it will cost me money to get this engine inline with today's modern engines and in a more usable fashion (for what I need it to do). Right now the only thing it has going for it is that it's MIT and has a world and plant editor.

That kind of statement will not win you friends around here. It also insults the intelligence of all the professional coders using the engine. Some people have spent hundreds if not thousands of dollars to make this technology available for FREE to YOU.

As to the problem at hand, I don't think it will be a simple change to get more resolution in the game world space. It may even be a limitation in DirectX itself. The change may require that the user is kept in a fixed position relative to the world space and move the world around the player. I think others may have a better grasp of the problem and can elaborate further.

#10 @Jimmy - I'm with Frank here. You've just joined this community, and already feel you can judge Torque as if you were absolutely familiar with it. While people like Frank and Michael have been here for years, and have contributed so much of their time and money to the engine and community that your comments just trivialise them, and everyone else here like them.

I'm pretty handy with the terrain system in Torque, and I can say without hesitation that this engine is one of the leading standards in terrain rendering. That you aren't able to leverage that power is not a failing of Torque, but of your own limited creativity.

By all means try and pull off in UDK or Unity what people like Konrad Kiss, Andy Wright and myself have done with Torque. And good luck with that.

#11 @Dan,
I don't think Jimmy meant to trivialize the people or the tech. I think he is not understanding the engine and how it works. Also, to be fair, because it is licensed under MIT a lot of people tend to associate free with lower value or quality. So it is an understandable mistake. I was trying to let Jimmy know that a lot of people have invested time and money in the engine and will defend it thusly.

If it looked like I was on the attack I was not trying to be. Lets not get out the pitch forks and torches just yet. :)

#12 Jimmy,

Using fixed-point math won't solve anything, but it's a good fix if you want to avoid the issue for as long as you possibly can. Integers have limits too. Using 64-bit floating point math will have a similiar effect.

What you can do is divide the world into segments and treat each one as its own coordinate system, with its own origin. This works but it goes deep into the engine design and isn't trivial to implement in an existing engine. Even commercial open-world games use the traditional approach (like T3D does). That includes high-profile titles like WoW or Skyrim/Fallout3.

It'll cost you money to get it working, I'm sure. But that's the case with 99% of the other engines too, you obviously didn't know and just threw that statement out here.

I can't remember exactly but I think the range where I saw unacceptable precision in T3D was at maybe 100000 meters from the origin (0, 0, 0) or something. We used to limit the world at that range and not let the game editor tool place anything that far out. 100000 meters is far bigger than Skyrims world, far bigger!

If I had to extend that, I would use 64-bit floating point math instead. I did that in an OGRE project once. But it's not as easy to just go into an existing engine and change it.

#13 @ Frank and Dan I meant no disrespect to this community or the tech behind torque.

Unity is crap I have tried it but with out the source code I won't be able to make it do what I really want for it to do for me. Your right I do have a very limited knowledge of the engine. The last time I messed with it was back in 2002 or 2003 (yes I was a license holder at that time).

Like i said before I would need hire people more knowledgeable then me to get the engine to the state that I need it to be in. There are several rendering techniques that are absent from the engine, 32 bit only, single core support, monolithic code base,(could be wrong) blah blah blah, as far as i can tell, for me those need to be changed.

Dan said

Quote:Also, to be fair, because it is licensed under MIT a lot of people tend to associate free with lower value or quality. So it is an understandable mistake.

For the most part that statement is true. Most OSS software is lower value. Most projects just want to keep the status qua going and not really innovate.

The thing is with developers and the communities that use their software tend to get "Tunnel Vision" on their product. So when an outsider like me comes in and gives some criticisms of the software everyone gets all hot and bothered by it. When in fact they should take a step back and see it for what it is. And yes this community is no exception. I have spent a lot of time over the last few weeks going over the forums and old post. I offer my criticisms so that this tech can have a larger adoption rate then other OSS products, by listing the faults of the current tech and to spur the community to develop a better product the the indie game developers actually need and would use.

From the last time I held a torque license not much has really changed feature wise, witch is sad really. But I have kept torque in the back of my mind for my project hoping that it would it would keep pace with the industry.

#14 Jimmy: My recommendation, look at what Dan, Andy Wright and Konrad do to get their terrains made(you can go through their profile to find various posts and blogs about it.

Torque's terrain system itself is actually pretty close to top of it's game(though some things do need improvement). The current weak link is the tools and how they're not particularly intuitive to making the best looking terrains as-is.

Of course, without a better idea of what you want out of the terrain, no one is going to be able to provide any additional advice. Just saying "Welp, I'm going to have to fix the whole thing to get what I want" may certainly be true, but you may save yourself hundreds of hours or thousands of dollars to use a way that some of the guys around here have found works just as well.

#15 @Jimmy,
I made that statement BTW.

You should read the Cathedral vs the Bizarre article about OSS development. It really describes the development process, the critical mass, and how going OSS will make the product better and more feature rich. T3D certainly has a critical mass necessary to go to the next level as an OSS project. T3D is very similar to Blender in that respect. BTW, innovation is often unseen and invisible. The reason is because you are not supposed to constantly innovate the API or you break everything.

T3D is so far advanced from TGE it is not funny. If you look at the product page here at GG you will see most of the features they tout were not in TGE. Rivers, forests with movement, wind, atmospheric effects, controllable fog, etc. From a coders perspective the engine is light years ahead. There is no unholy dependence upon Shapebase like there was in TGE, the rendering is modularized so it can be replaced, convex and concave collision, and lots more.

Then go look at the addons you can buy. Path finding, particle packages, shaders, AI packages, art packs, etc. You could buy every addon and not even get to the minimum licensing cost of Unity for example. You certainly would not get anywhere near the licensing costs for say the Unreal engine, or the Source engine. Also, there is no reason you can't go grab Ogre or any other package that might suit your needs better and splice that in. Now with it being MIT you can ship the editors as well.

#16 Jimmy: what exactly are you trying to do with the engine? I'm sure we could be a lot more helpful if we knew where you were heading!

#17 @ Frank I have read that article, it is several years old by now. And yes I agree Torque has the critical mass, but most of the OSS out there do not innovate, example gimp and the lack of support for 16 grey scale export feature. Last I checked they can still only do 8 bit. Now don't get me wrong they are making great strides in other area's but at the cost of basic functionality that is decades old and they still don't support it (last I checked) Blender is a anther good one. They finally got hair in when they did the Sintel movie about 4 to 5 years after the major 3d packages. But their interface is horrible.

I have followed oger over the years it's a nice engine and all but I don't like how it renders......I actually like the look of Torque render

@ Daniel Well I'm not trying to run on old hardware that is no more then 5 years old. It doesn't matter what kind of project I would like to do. It matters if the tools I choose to use will do the job. Right now it all about getting some more modern features into the engine that is supported by the big dawgs engines. Graphic fidelity is what I'm talking about.

The first thing that comes to mind is adding vertices weighting, IK based animation, animation blending(didn't see that in my limited perusal of the code.) 64 bit support, multi core support, mutli threading support, direct x 11 support getting rid of the torque script and implementing probably Mono as a JIT for scripting. the usual suspects.

But I think that this has gotten a bit off topic. I'm not dissing torque one bit. I think my earlier remark was taken wrong. In every project their needs to be some code rewrite to support what you want the tools to do. I was trying to gauge wither the community was working on features that you see in the $$$ engine packages or if they were just going with the status qua for now so that I can gauge on how much I would need to pay for people to implement the features that I would need for my project.

#18 @ stefan I just saw your post.

Quote: I can't remember exactly but I think the range where I saw unacceptable precision in T3D was at maybe 100000 meters from the origin (0, 0, 0) or something. We used to limit the world at that range and not let the game editor tool place anything that far out. 100000 meters is far bigger than Skyrims world, far bigger!

That's insane I would like a big world but not even the commerical engines go that far out form (0,0,0). Do you have a link to a tutorial or something so that I can test this ?

Quote: If I had to extend that, I would use 64-bit floating point math instead. I did that in an OGRE project once. But it's not as easy to just go into an existing engine and change it.

I was thinking of using 64-bit floating point but what you say is true then I wouldn't need to go that far I could just use the terrain engine as is and just to make ,or pay someone else, to do the initial changes to support a larger world size.

#19 very few games support even large paging worlds, most simply opt for teleportation or some form. some do it really really badly, like NWN2 for example, or the original Witcher game.

Some do it seamlessly WoW for example and some dont even really have terrain like oblivion and i'm assuming skyrim.

#20 WoW uses both portals and zones. It is really jarring in most games that have a bad zoning set up. Yes few games support paging worlds witch is actually disk streaming and you need to do that to both terrian and game objects.