Re: [hlcoders] Question on map loading

2011-05-24 Thread Psy_Commando
I've hit another wall. VRad crashes when there are like 7 separate tunnels boxes. By tunnel boxes I mean, separate boxes made of 6 brush, each with skybox texture for the ceiling and walls, and the dev floor texture. It crashes in a function with Winding in the name. I can't remember the entire

Re: [hlcoders] Question on map loading

2011-05-23 Thread Jed
You might want to try and get in touch with Tim Waldo Holt. He was experimenting with various game engines and procedural terrain generation to simulate large areas of forest based on geodata. I know he used Source at one point and had the same problem that you have - maps are too small - and he

Re: [hlcoders] Question on map loading

2011-05-23 Thread Psy_Commando
Thanks, I may give it a try, but I checked his website about his forest fire simulator, but he seems to have gone for another engine completely. I think I should be able to do what I want with simply scaling down. At least, until I hit another wall. The completely new map system also sounds like

Re: [hlcoders] Question on map loading

2011-05-22 Thread Psy_Commando
Thanks, for the answer, but we are already using this solution. The main problem with it is that the collision mesh gets horribly mangled by the model compiler. Now that I think about it, I guess we could split the model into smaller convex chunks. However, I don't know if it would be a pain to

Re: [hlcoders] Question on map loading

2011-05-22 Thread Saul Rennison
If all you want is massive extending terrain then: You could make your own terrain, and pass the mesh directly to the materialsystem and then your co-ordinates would only be bound by float limits. Also, you can make your own physics collision mesh by creating a polysoup (see the VPhysics

Re: [hlcoders] Question on map loading

2011-05-22 Thread Psy_Commando
Woops, yeah, you're right about that. But then there's the view frustrum that will be inadequate for following the tiny ship. I remember my teachers warning me against going below 1.0f for the front clipping plane's z. Is that accurate ? On Sun, May 22, 2011 at 3:15 PM, Tom Edwards

Re: [hlcoders] Question on map loading

2011-05-22 Thread Psy_Commando
Thanks, that sound like a possible alternative. But what do you mean, pass the mesh to the material system ? On Sun, May 22, 2011 at 3:26 PM, Saul Rennison saul.renni...@gmail.comwrote: If all you want is massive extending terrain then: You could make your own terrain, and pass the mesh

Re: [hlcoders] Question on map loading

2011-05-22 Thread Saul Rennison
Literally create a mesh via CreateMesh, populate is with your vertices, bind a texture to it then draw it. I'm not 100% how it works but it would be quite simple to adapt some DirectX heightmap code to use the materialsystem instead of direct API calls. Good luck! On Sunday, 22 May 2011,

Re: [hlcoders] Question on map loading

2011-05-22 Thread Psy_Commando
Hey thanks for the idea! I think I could work out some kind of hybrid map system, so I can fallback on bsp. It might turn out a little complex, but it's worth a try! Hell, I could even code an in-game level editor On Sun, May 22, 2011 at 6:04 PM, Saul Rennison saul.renni...@gmail.comwrote:

Re: [hlcoders] Question on map loading

2011-05-21 Thread Skillet
The solution that Empires and Eternal Silence used (AFAIK) is to shrink down everything including the player so that the effective map size is increased. Relatively simple idea and seems to have worked well... On Thu, May 19, 2011 at 4:25 PM, Psy_Commando psycomma...@gmail.com wrote: Hi. I

[hlcoders] Question on map loading

2011-05-19 Thread Psy_Commando
Hi. I know nobody was able to actually change the hard coded map size, but I gave a try anyways. And as expected it didn't work. Hammer don't want to load.vmf with solids further away than 16384 units from origin. And that's hard-coded in hammer, since setting @mapsize(-32768, 32768) in the