 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
Probably 4 bytes? Quake was released >5 years before the first amd64 cpu after all :)
Every GameObject has a mesh collider on it! Each object gets:
- A material that's created at runtime using the texture I ripped from from pak0.pk3 and the lightmap decoded from the - A mesh that's generated at run-time using the verts and tris from that face's entry in the - A mesh collider, which is the slowest type of collider Unity has, but since each face is typically small, and is sure to be convex, it's actually pretty fast. I had planned to implement the bsp tree to help reduce the number of gameobjects, but it looks like Unity does a fine job on it's own. I've run a bunch of the stock Q3 maps and some pretty sizable custom ones on both a crappy laptop with a Core Duo and ancient Intel graphics, and on the Ouya, which has a terrible Tegra3, and it runs very well on both. I suspect Unity does it's own judgement on what objects need to be rendered and what colliders should be checked against, and it seems to scale very well. From QuakeOne.com forums:
byte+char are both 1 octet, short is 2 octets, int+long are both 4 octets, long long is never encountered. Octets in this context being equal to one byte. Ah ok, so your collision mesh is just a duplicate of the render mesh essentially.
I was just wondering if you'd found a way to somehow process the bsp collision data, so you could take advantage of clip brushes etc, which would simplify the collision geometry somewhat. In theory you could just skip adding mesh colliders to the faces as you made them, and then create meshes from the bsp brushes in the map, and a collider to them, and skip adding a renderer, so you have an invisible clipping brush. That would be needed for sure on some maps, where simplified collision stops the player getting hung up on detail in the map.
I have it mostly working. Geometry is recreated, and texture coords are calculated correctly. Or at least I think they're correct, they scale and move like I expect them to playing around with them in trenchbroom.
Getting verts for each face was a little confusing at first with the double-lookup method it requires, but it wasn't that difficult. Same for texture coords; a little confusing at first, but simple in the end. As a stress-test I loaded up Sock's Ivory Tower, and the result is a CRAZY 32k GameObjects! THIRTY. TWO. THOUSAND. OBJECTS. http://imgur.com/sNHWsmf Marking the objects as static lets Unity batch them together, resulting in only about 2-5 draw calls at any given moment. It's very slow to start up, likely because right now I am making a ton of Lists as I make each object, which was helping me squash bugs. Now that I have the process down I think I'll be able to simplify it and speed up startup. Getting there! Congrats on that.
Qunity Quanity Quakity Quakey... About collisions, I thought the whole saving of visual / hull collision was marginal anyway by modern tech? Does / would it have any discernible impact on modern machines? If you really want something to stress test your unity map converter program I recommend you try my Map on the Edge of Forever. All of the source files are freely available, it has full HD textures and new environment sounds with spoken dialogue.
If you can get some simple game logic (pushing/shooting buttons) and Q3 style shaders working it would easily run standalone in Unity! @ijed
Really there's no performance need to have simplified colliders anymore, at least not using Unity. The main benefit would be to stop players from getting stuck on detailing. Players love to glide along walls and assume they'll just slide along the wall without getting hung up on the grates and torches. @sock Would love to have larger maps like this working well. I'm going to have need some optimization before I get big maps working well. I replaced all of my Lists with arrays in the object generator, but startup performance with large maps didn't increase much. Premature optimization is the bane of many a project, though, so I think I'll focus on getting smaller maps (like my lame remake of dm_stalwart) working with textures and lightmaps before I start looking to juice performance. Really big maps then let me know :)
Would all be in bsp2 format, if that makes any difference. Not sure how it would react to a BSP2 map. Could you link me one? Just got textures working and would love to give it a whirl.
On the topic of textures, I have them reconstructed correctly. I went full old-school and created textures by using the indexs from the What's not pixel perfect is the scale of the textures. I've used the dotproduct to generate the texture coords for the verts, and they are rotated correctly, and their scale does change how it should when I adjust it in trenchbroom, but they still need to be scaled up, there are too many tilings of a texture on any given surface. I noticed that it says to divide the result of the dotproduct by the texture width. Could you elaborate on this a little bit? I'm trying to do that, but I end up with a strange minecraft-esque texture. Screenshot showing ivory.bsp loaded:
http://imgur.com/DukiW4C Not going to be able to rely on Unity's batching to save me, since all the textures are generated at runtime. Will think of something clever, I'm sure. I have textures working perfectly now. Scaled and everything. The Ivory Tower is looking much better!
http://imgur.com/ueMK4Qa The only bug I'm running into now is when I try some maps from Quaddicted. Some (most older) maps don't load because I end up with invalid texture dimensions. Newer maps are working fine. Here's Q-Deck. http://imgur.com/dt9JFcW Some old maps work fine. Like this one: https://www.quaddicted.com/reviews/deso.html I've noticed in maps that don't work that there are textures that start with z that seem to be the only ones getting incorrect data pulled. An example is https://www.quaddicted.com/reviews/fmb6.html Anyone have any insight into this? It doesn't seem to be me reading the wrong size data, as the textures in the map that don't start with z read correctly, and show sane dimensions and offsets. It's only the "z" textures that are screwy. Here's the github for this if anyone is interested. Just like the Q3 version it's free to fork/copy/whatever.
https://github.com/mikezila/uQuake1 (Think I'll let the weird Spanish translation stand for that one)
ALLCAPS, I can send you a true bsp2 map in a couple of hours; back to the office today. Do you just need the bsp? The dropbox folder (mail etc. sent).
The BSP inside 'should' always be a fullviz, if that matters to the port process. If not then I can upload one quickly enough - it takes about 10 minutes to compile, using Tyrann's tools. Vis data is not used (or even parsed) currently, so that won't matter. I do plan to implement it in some capacity, but haven't yet. Trying to tackle the performance of loading big maps first, so that I don't end up having to refactor a bunch of stuff. I suspect implementing vis will cause/require me to change how I generate my objects, and before I do that I want to see what performance gains I can get.
If your meshes were grouped together better, then I'm sure you could use unity's occlusion culling feature (pro unity only tho)
In theory you could just skip adding mesh colliders to the faces as you made them, and then create meshes from the bsp brushes in the map, and a collider to them, and skip adding a renderer, so you have an invisible clipping brush. That would be needed for sure on some maps, where simplified collision stops the player getting hung up on detail in the map.
If you have access to the 1) You could detect which brushes are essentially boxes (probably a lot of them), and use box colliders for them instead of mesh colliders. 2) The non-box brushes are still guaranteed to be convex, so you can enable the convex flag on their mesh colliders, which I'm sure helps.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |