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.com>wrote: > 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, Psy_Commando <psycomma...@gmail.com> wrote: > > 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.com> > wrote: > > 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 interfaces). > > > > > > > > In effect, it'd be a custom displacement system. No idea how you'd get > this to work in Hammer. > > Thanks, > > - Saul > > > > > > > > On 22 May 2011 19:55, Psy_Commando <psycomma...@gmail.com> wrote: > > > > > > > > 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 animate and > properly assign bones? > > > > And there's also the issue that in multiplayer games, coordinates are > limited to 3 digits precision after the decimal point, so anything more > precise than 0.001f would get floored. I'm not sure what would be the > immediate effects of this though, with the client interpolation... > > > > It's such an irritating problem, it would probably take me less than a > day to patch, if I had access to the code that loads the bsp and build the > map mesh... I even investigated where it didn't work, comparing the debug > messages and the old leaked beta code. I could have probably bypassed the > current engine code and replaced it with some code from the leaked beta > engine, but I can't use that stuff because it's illegal! :( > > > > > > > > > > On Sat, May 21, 2011 at 11:26 PM, Skillet <skillet5...@gmail.com> wrote: > > > > > > > > > > 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 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 "base.fgd", won't change anything, except the grid size in the > map editor. > > > > And even when tweaking the datatype of bounds in vbsp, vrad, and vvis, > just resulted in the engine dll crashing on load with a "funny lump size" > error. Because I guess, the lump size are constants in a shared header. > > > > So I got two questions: > > > > Has anybody tried to contact valve about that, or play around with that ? > > Because we have the source for all bsp stuff, but we can't make lumps > bigger or smaller, because the code that loads the actual bsp is > uncooperative, and inside the engine dll. If they could query a couple of > constants via the server dll interface for various lump sizes, or map bounds > typedef, that would be much appreciated. > > > > Any idea or suggestions on how to make a space shooter with the source > engine ? > > We're using corridors with teleports at the end of each to take the ship > to the next corridor. > > There also the make the world move around the ship approach, but we cant > move displacements with collision... > > > > Any comments or advices are welcome. > > > > _______________________________________________ > > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > > > > ______ > > -- > > Thanks, > - Saul > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > >
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
