 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
|
Hosting websites on Dropbox is only meant for short-lived temporary sharing, please upload to Quaketastic or your own website?
Page cannot be crawled or displayed due to robots.txt. See dl.dropboxusercontent.com robots.txt page. Learn more about robots.txt. only if you select standard. If you select the other 2 modes, it will create 1 brush per face.
Going standard and convexorizing your geometry yourself works really well though. when you have a lot of faces to process, this can take several seconds. you might consider adding a progress bar as currently, the window just freezes and the icon disappears from the taskbar until it completes.
I always meant to do that
users will always find a way to break your software, especially if that user is me!
i think the only real weirdness is the way it vanishes from the taskbar while it is working and doesn't reappear until you click ok in the dialog box that pops up when its done. it makes it look like it closed if you bring another application into the foreground and can't see the window anymore. There is a bug.
In some countries we use commas to separate float part instead of dot, and now it tries to find comma by default on my machine = Exception Thrown. Easy to fix. When you parse obj's vertices do CultureInfo("en-US"), like this: double.Parse(strArray[1],new CultureInfo("en-US")) It will force Parser to search for dot. Btw. are you not interested in releasing it as Open Source? We could improve it! :) Cheers! this is something that only really comes up when you're working with this tool the way I am, but it would be cool if you could save settings specific to certain models, so when I convert an obj for the first time, it writes a text file with all your current settings beside the
i try this one
willem -AT- wantonhubris -DOT- com Vote for obj2 map, makes your life a breeze! Now more tris free!! i have had some map files recently that troubled me and my minions. Basically it was a parsing error that stopped all editors from loading the obj2map output.
Modo files works a charme, these hassles came from Z-brush files that were either scaled bad or what do i know. I dont have a clue right now, i can sent you all assets for a check. Sure. mfx , can you upload some example OBJ / MAP file that doesn't work? You can export just simple object that gives broken results. I would like to take a look and maybe find some solution.
My new website is www.warrenmarshall.biz . Email is warren @ that domain.
But yeah, post it here maybe btw I did small patch for OBJ-2-MAP for myself. Dot/Comma problem fix + settings saving (to xml per model) If Warren don't mind I can release it as unofficial binary patch.
Sure
I told Eric this but I might as well make it official. I apparently lost the source code to this. It must have been during my transition from Epic that it got lost in a crack somewhere and deleted. I've searched high and low and So, I apologize. If anyone wants to reverse engineer the EXE or whatever kids do these days, I don't mind. Go forth and do whatever you like. It's honestly not that complex an app so maybe something should start up an open source version of it or something so everyone can pile in fixes and features... This is my karmic retribution for not allowing the source to be downloaded right from the start.
Smooth move, Warren! Thanks!
Yeah I have reversed source, even Designer's window form is in the project. Variables have generated names, but that's easy to correct. I'll add informational comments and release it in some private git repository, so we can check out if everything is fine before public release. We need to think what licence we want to apply, or maybe we'll keep it as private repo for community only? Wow, that's amazing you were able to decompile the whole thing :o
So it is actually an openable project now? Hey!
I'll prepare git repo next week. Sorry you need to wait, I was extremely busy last days and I'm heading on 4 day holiday atm, so I'll be away from computer till Monday (I'll lurk from mobile ;) ) Here you have binary, so you can use my latest changes: http://78.47.23.219/OBJ2MAP_111.zip It saves settings to XML file (OBJFileName.xml) when you hit GO! and load settings when you choose OBJ file. Happy mapping! I have tried many times trying to get blender OBJ export to work with this tool, but each time I get a NullPointerException in the debug window.
ShoTro have you tried this build: http://78.47.23.219/OBJ2MAP_111.zip ?
I have used it with blender and had no problems. eric
There's a repository that Kreathor set up over here https://bitbucket.org/khreathor/obj-2-map/wiki/Home The source has actually been updated and had a few features added Looks like it's a private repo, I just asked kreathor to add me.
I'm going to try doing import of UV's and texture names from the obj file. If the model is triangluated and you export to Valve220 it should work flawlessly. There's a fewest-planes wrapping algorithm floating around somewhere that would be ideal for exporting weird shapes like dragon heads in an optimum minimum number of convex brushes
Just out of curiosity is it possible to use valve220 map formats to make quake1 and 2 maps for the compilers?
This has probably been asked a dillion times, but does the
.bsp ultimately does not give a crap since its turned into pure polygons with uv coordinates.
In fact you could in theory edit the texture mapping after a compile and replace it. its only quake3 that has actual xyz+st+lmst+rgb coords. the earlier versions all calculate everything based upon the xyz and their texinfo's texture planes (basically like valve220 with the scale+rotation things baked in to the plane itself).
this means the (software) renderer can generate the s+t coords dynamically after clipping, instead of having to clip those s+t coords to the screen too and getting extra imprecision+inefficiencies from doing so. Wait, really? So
Don't tell me that's true This was a lot more of a pain than I thought, lol, but I think I got it working, Here is a beta.
If anyone tries it out: Before doing the conversion, you have to add all of the textures used by the OBJ file to a Quake WAD, and put it in the same directory as the OBJ. (The reason for this is OBJ2MAP needs to get the Quake texture sizes is order to write the correct texture axis values.) Secondly, the texture names are read from the "usemtl" lines in the Finally the output is Valve 220 format only, so this is only usable with Hammer/Jackhammer/TB2/etc. Future ideas: - read - automatically read in the images referenced by the OBJ and convert them to a WAD file? I included a sample model (from xonotic) that I was testing with, along with a texture wad, so you can see how things need to be set up for it to work. source code is here This should make for some crazy maps in the future if this works as I imagine it too...
Crazy! Can someone post some screenshots of it working? :P How much freedom is actually possible here?
Or, a better question I'm getting "Error computing texture vectors" in log.
Ericw I can send you an OBJ if you want. It's quite big. Everything exports except UVs. Exporting simple box works lol :D I was looking at code but have no clue why it's not working atm. Need more time to analyse your work :) Ohhh... and in Jackhammer Y Scale of tex is 0, so you need to change it to 1 manually... Only limitation I'm aware of is, if the
Other than that, it seems to work as expected, it'll shear/rotate/scale/offset the texture as needed so the UVs line up. I just have this ugly robot model (same one that's included in the obj2map zip) for a screenshot: https://www.dropbox.com/home/quake?preview=walker.png I just wanted to export "shit" like this: http://78.47.23.219/head_obj.jpg
Maybe I was too optimistic :D here's the working link: https://www.dropbox.com/s/a9zgelk79nq9zol/walker.png?dl=1
khreathor: dunno, should be possible :P Thanks, just got your email. So I gave it a spin and it does some things right and others wrong with my current setup as far as I can tell.
Here is a screenshot showing my lovely test cylinder in 3dsmax and the resulting data inside TB2. https://dl.dropboxusercontent.com/u/1849053/OBJ_Mapped_Error.jpg For starters when I load my wad file it applies all the textures correct. But for some reason in 3dsmax its taking the name of the texture from the material name? And not the actual texture loaded. Oh well I can make that work. It does get the tiling amount correct for the top but the side faces are skewed. I do believe TB2 supports Valve220 though unless I missed something. I've also included the OBJ output from 3dsmax and the wad file I used. https://dl.dropboxusercontent.com/u/1849053/cylinder_test.zip I think you set everything up correctly, but when I convert your obj it looks fine.
Old build of TB2 by any chance? Double check in Jackhammer? I got same results with cylinder as Skiffy...
Tested on Jackhammer 1.1.700 Log full of "Error computing texture vectors". I just wonder if it's not another problem with dot and comma conversion. In some EU countries we use comma instead of dot, to point floating part. During computation Parse is doing wrong conversion or something like that and outputs rounded results or throw exception. That's why I added "Culture" thing to force dot... but I found maybe one place in the new code where you can add this, but it shouldn't matter tbh. Gonna check it in a moment. EricW can you sens us MAP file with this cylinder? Still not working properly for me... I think I'll debug it step by step, after I finish other stuff. Can you upload cylinder MAP for me? I wanna see how far values are from proper map file.
here is what I get: https://www.dropbox.com/s/e06wzg0zz43seot/cylinder.map?dl=0
What is a good simple (as in learning curve) modeller to use for this? I've tried TB, Quark, and JH / Hammer to make maps over the years. But have never tried using a modelling program (other that POVray with Moray).
I just lost 8h of source debugging, line by line, with calculator and shit, to realize, it was all fault of "Axis Aligned?" checkbox... -_- fckin' checkbox...
@#$%!!! Results are amazing man... <3 https://pbs.twimg.com/media/CRK0TILWcAEZB2W.jpg:large You deserve a medal and sixpack of a beer! I think new era of Quake mapping just started :D sorry you had to go through all that debugging, but awesome that you found the problem and it works! argh, I must have always been testing with "Axis aligned" unchecked..
did you try the beta 2 version? I updated the download in post #66. that should fix the cylinder model if Windows is set to use comma for the decimal point when printing numbers.
You probably have set Method to Standard, it wont work with this unfortunately. You need to go with Extrusion or Spike.
I think it's not hard to turn off this Alignment in code for Standard too. Will take a look later. I use standard because I construct proper BSP brushes for various things instead of relying on the extrude or or Spike method. So yes indeed I would prefer to have the standard one working too.
http://panjoo.tastyspleen.net/rust/tutorials/brushcreate/brushes.htm This is what we did on Gunman Chronicles back in 2000 :) We used to have a tool similar to OBJ2MAP but it got lost in a HD crash source and all. But hey now we have this improved monster! :) you worked on gunman TC? i remember being really impressed with the screenshots I saw of it at the time. (when it was a quake TC)
Especially the giant hand sculpture. Gunman Chronicles was neat fun. You would think that sculpture would be among the top image results for the game but...oh well :^|
Yea I was the main modeler / animator on the project back then. So all enemies and guns plus tons of props modeled / animated.
and I remember some of the cool models, like the Star Wars like monster that comes out of the ground.
Known as the Xenome Grande, very creative.
Large Alien in Spanish hehe. That sucker was sculpted in clay and then surfaced using a microscribe and Amapi the modeling software with good drivers for it back then. It was a pain in the butt to animate. I had no clue how to setup spline rigs back then. So FK tentacle animations all the way! woot!... :P I haven't got time to compile and test it in game, but with BSP2 it should work without a problem.
It compiles just fine, but to BSP2 (of course):
https://pbs.twimg.com/media/CRbN3SJXAAADXU3.jpg:large https://pbs.twimg.com/media/CRbN4pBWcAAPPHT.jpg:large (If link doesn't work here is direct tweet: https://twitter.com/khreathor/status/654937170508124160) After trying out some complex forms I thought it better to start with simple forms to get grip on this handy program.
So I started with a cube and tetraeder and that worked well. My cylinder doesn't come out. So I assured myself the points were on grid, used noesis to convert it again, as my *.obj files didn't seem right. What I tried looks like a cylinder, but I needed the spikes method, otherwise there were some blended side patches and the form was not editable in quark. Now it has the form but the patches are glued inwards. Your map file looks fine to me as far as the geometry goes. The cylinder is open at the ends so you can see the ugly spikes generated by the "spikes" method, that's normal.
Whose email is outdated btw? For the texturing, try downloading the tool again from post #66, you have the older version; it should say "UV conversion beta 2" in the title bar. Your obj file has "usemtl UnKnown0", so you need a wad file in the same directory with a texture called "UnKnown0" for the UV import to work. I sended an email to warren.marshall/dot/epicgames/point/com.
That's the email adres on the linked site and it didn't work. I saw there's another one in "people" so I guess it is altered. I will try the updated one, maybe it has better results. This one brings up a cylinder with triangles messed up to the inside. I expected a smooth round outside. thanks for the hint. I don't work at Epic Games anymore.
But regardless, any UV stuff is really Eric's Hey there,
I've been looking for something like this for quite a while for mapping with COD: WaW and COD 4, but I just cant get it to work the way I want. It seems "extrusion" is more than likely the mode I'd want to use (as I want to recreate a map from a 3D model. I've used OBJ exporter for 3DSmax 2015 which seems to have exported properly. I've removed all textures (as I don't mind re-texturing), so in OBJ2MAP i've typed caulk in place of DEFAULT so COD WaW Radiant will read it. Unfortunately due to the conversion process, it's just got too massive in scale, and there is no option to reduce scale on OBJ2MAP. Any ideas ? Thanks in advance. I totally must have had a mans look. Just saw the "scale" % field. It still crashes at Extrusion though (Unhandled Exception). It makes me have to exit the program and re-load it, otherwise the log file is "in use" by another process.
That's odd. Does "Spikes" crash as well? That might work for something modeled in Max as well.
Also, try checking or unchecked the 'axis aligned' box and see what happens. Crashes on Spikes as well. Tried both combinations (with and without axis aligned box) and it does the same thing. I wonder if its Windows 10 related...or maybe I need some Runtime files that you have and I don't.
************** Exception Text ************** System.NullReferenceException: Object reference not set to an instance of an object. at OBJ2MAP.XVector.Multiply(XVector _V, Double _Scalar) at OBJ2MAP.MainForm.GoButton_Click(Object sender, EventArgs e) at System.Windows.Forms.Control.OnClick(EventArgs e) at System.Windows.Forms.Button.OnClick(EventArgs e) at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ButtonBase.WndProc(Message& m) at System.Windows.Forms.Button.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) ______________________ All I'm getting when I get it to make a map (which takes bloody ages) is a bunch of jumbled (but joined) brushes which I can only manage to load into trenchbroom (although i'm trying to get it into COD Radiant. There is no pattern there, it's just a jumbled mess. Radiant throws a fit and tells me it's missing a { no matter how many times I compile it. I think maybe I'm just expecting too much from this..single models it will no doubt work, but a whole map is probably just too much for it to handle. How many faces is your model? I was able to convert a whole map's worth of geometry for terrain without problems from obj2map, so it might be something else. I used max 2009, possibly the obj format is a little different in 2015?
Summary:
Vertices: 33410 Faces: 12 Brushes: 202 It is possible that the obj is getting corrupt in the conversion process I suppose, but I can load it perfectly into windows 10 3d builder and Blender. I can not get anything to export the Which build of obj2map was that with? Maybe try the beta in post 66; I remember fixing a bug with a similar stack trace as what you posted.
Both versions (1 and 1.1.1) did the same thing. I'll try this beta (extrusion\grid align locked it up to a "not responding" state), so I'll try the other combinations and let you know
Standard\axis aligned : Stuck on "Adding brush 0 to map" - Not Responding -..took 40 mins to get the brush 1
extrusion\axis aligned : Stuck on "Adding brush 0 to map" - Not Responding extrusion\no axis aligned : Unhandled Exception System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index Spikes\axis aligned : Stuck on "Adding brush 0 to map" - Not Responding Spikes\no axis aligned : Unhandled exception - The path is notof a legal form. Ok, installed 3dsmax 2009, Re-ripped and exported the OBJ again (successfully). Same errors as before. Must be Windows 10 related. I'll try on other PC's around the home when I get a chance
Summary:
Vertices: 33410 Faces: 12 Brushes: 202 I mean what were the stats in Max. Also the above numbers don't make any sense. 12 faces with 33k verts? As a reference, I was successfully able to convert a mesh with 5k triangles and 2.5k verts into a map file from Max2011 (sorry, i said 2009 earlier). I've uploaded the file to my ftp. Now please note, this is a private project, and the contents DO infringe copyright. So please delete it once you're done, as it's not mine to distribute. I'll be deleting the file off the ftp in 24 hours.
www.leviathan.net.au/nuke-rebuilt.obj That's what the OBJ converter does from 3DSmax 2009 and 2016. It loads fine into Win10 3D builder and blender, but as far as map conversion..I think i've hit a wall. (so to speak) :)
Mesh is just a massive cloud of orphaned vertices.
I'm all for experimental maps and whatnot, but... I'm guessing from the googie look and file name it's something Fallout related?
I mean, maybe break it down into smaller chunks or something but :
(a) it's absolutely immense - MODO tells me there's ~163,000 triangles (b) there's a mountain of triangles (none of which are anywhere near a grid, I'd wager) (c) I think it broke when loading into MODO, to be honest, as there are missing polys everywhere, tons of overlapping stuff, etc. Just I loaded it into MODO and I had to flip it upside down to make it look right. Then 90% of the tris are triplicated, so ran a poly.unify on those.
Even then it's still a mess of weird orphan objects floating in the middle of nowhere, partial houses, and broken terrain. Yep, I totally agree with all of you. It's a bloody mess. Just needed more opinions before I threw it in the "too bloody hard" basket.
Anyway..Treyarch just announced mapping tools for Black Ops 3, so making new Prefabs is the next project instead. Thanks for all your questions\answers on this problem. Eric, can you add your source code into the main repository? If it's there, I apologize, I'm not too familiar with this stuff
Anyway, bug report Yeah- all my code is up on bitbucket, I was working on my own fork here: https://bitbucket.org/ericwa/obj-2-map/commits/all , but khreathor pulled all of my texturing stuff into the "wip" branch of the main repo.
yeah I merged it into wip branch, because I wanted to keep old stable source. It will be good to make some radio button where you can choose between old and new method, classic MAP and Valve 220 MAP. What do you think?
Latest compiled version of this treasure anywhere? Not sure how best to go about compiling the one from the repo...
afaik, the latest builds are post #47 for the regular version or #66 for UV+texturing import.
Compiling it is pretty easy, install VS Community 2015 (large download), double click the Ah cool thanks. Just wondering but did anyone use this in Arcane Dimension or any other recent maps yet?
I've used it for pieces in maps
I haven't done a full map tho, no. That would be How long does vis take with such a map?
I imagine this style of design wouldn't lend to big maps with lots of monsters because there would effectively be no visblocking (or am I wrong?). I imagine you're not literally suggesting surrounding it with a big box, but rather having a boxy structural hull that still essentially follows the layout of the map?
Otherwise: (reaction.gif) What would be the drawback of building your map out of simple brushes, and then when you need detail that requires using techniques that often cause invalid brushes / microleaks (such as vertex editing), just adding such things as detail brushes inside the already built and sealed structure?
As an example, let's say I'm doing a section where I have rocks on one wall of a room. I'd build that wall using a simple cuboid brush that seals the room, and then add the rocks as detail brushes. Is that feasible, or do detail brushes cause other headaches? I'm pretty sure that's more or less how everyone has mapped since detail brushes became available. I may be wrong.
I've heard (but not looked into it myself) that detail brushes that stick through the structural hull and into the void are problematic - does anyone know anything about this / elaborate?
I would advise against that anyway. Build the detail brushes flush against the sealing structure.
I'm trying to put together some best practices for the TrenchBroom 2 manual. "I would advise against that anyway. Build the detail brushes flush against the sealing structure."
Why is that? Afaik detail brushes don't care where they are. func_ objects that are in more than one leaf, or that stick out of the world, can have the entity flicker problem though.
Details are part of the bsp though, so if you can see em, there they are. The bug they can cause is when a mapper either on purpose or mistakenly uses them to seal a leak, inadvertently creating one. The bad practice is making everything in the world detail, apart from your outer hulls, effectively trading off vis time for performance. This is usually unnecessary, but also kind of subjective over 'when' it becomes bad practice, depending on your geometry. Oh, but UE and other engines has a portal system that Quake 1 doesn't have (not that I know of). Does Quake 1 have hint brushes?
I mean, you can make the sealing walls world and the rest detail, as BSP + meshes in UE. But you don't have any tool in Quake 1 to manually tweak VIS behaviour, like Q2's hint brushes.
Modern quake compilers do have "hint" texture support to force a BSP split. Never tried it myself.
Oh, but UE and other engines has a portal system that Quake 1 doesn't have (not that I know of). Darkplaces has "r_drawportals 1" which is cool for viewing the portals/leafs. There's also a gtkradiant plugin that can load prt files generated by qbsp. I would advise against that anyway. Build the detail brushes flush against the sealing structure.
In Q1 compilers, func_detail brushes take part in CSG (clipping away overlapping geometry) and outside filling (clipping away anything that faces the void) just like world brushes. This is unintuitive, imho, and means you can't just build a sealing structure and completely cover it in detail, because the detail will clip away the sealing structure. e.g. If you have a long corridor and cover the floor/ceiling/side walls completely with func_detail rocks to make a cave tunnel, you'll get bad vis quality (vis will see through into other parts of the map). otp, regarding a giant box filled with func_detail, that would be the same as unvised as far as performance in engine. In fact it would be better not to vis it so the engine doesn't waste time doing useless tests against the vis data which is all '1' (every leaf can see every other leaf). Just tidyness. I know that in general qbsp doesn't mind clipping overlapping brushes. However Having brushes align and not overlap makes for less visual clutter in the editor.
But that said, I wouldn't be surprised if even though it appears that qbsp doesn't care, having overlapping brushes has other ill effects esp. if entities are involved. But I have no proof of that. "But that said, I wouldn't be surprised if even though it appears that qbsp doesn't care, having overlapping brushes has other ill effects esp. if entities are involved. But I have no proof of that."
Yeah, there are many urban legends regarding overlapping brushes. I'm a believer that it doesn't matter at all but I know there are others who have strong feelings the other way. To me, it's a bunch of busywork to miter everything but what-ev... Overlapping brushes don't matter at all to the resulting hulls in my experience, i guess you talk about the case where a plane is represented by 2 or more brushes.
In that case i only care for the sides which share the plane to have the same texture alignment/ratio/angles. You get it. Of course this may produce weird portals for vising, and the face splitting isn't always ideal in other cases resulting in lightmap errors and and and. So better not do it if you can avoid it. :) e.g. If you have a long corridor and cover the floor/ceiling/side walls completely with func_detail rocks to make a cave tunnel, you'll get bad vis quality (vis will see through into other parts of the map).
I still don't get what the problem is here - you'll end up drawing more because the visibility err "chunks" are more coarse-grained, but how does that make an important difference on today's computers? I still don't get what the problem is here - you'll end up drawing more because the visibility err "chunks" are more coarse-grained, but how does that make an important difference on today's computers?
I think ericw is worried not that simplified visblocking has slightly worse performance, but that you might accidentally have no visblocking from your tunnel at all. In other words, there can be no difference between building detail brushes around standard brushes, and only using detail brushes for the corridor. The former case gets reduced to the latter if all the standard brushes get clipped away by the details - and it's not obvious that detail brushes pose this risk. ericw, preach:
So are you saying that the only parts of a structural brush that can contribute to visblocking are the parts of that brush that remain visible in the map? I kinda assumed it worked more like quake 3 where the structural brush can be completely covered by the detail. This changes everything :( Well, I can't speak authoritatively but it's only logical that VIS can only work with the visual faces in a BSP as that's all it has once it starts working. It doesn't work with the MAP file, it reads and writes the BSP.
But that doesn't make a ton of sense to me
I just tested this. Two box rooms connected by a horseshoe hallway, no visibility between them.
Lining the walls of one room with detail brushes does indeed permit visibility into the other room. Plus, because vis is assumed to be two-way, you can see into the detail-brush-lined room from the other room, too. A small detail brush in the center of a wall does not create a 'portal' with which to see into the other room, however. Extending that detail brush until it almost covers the wall behind it, with an 8 unit margin around the edges, also does not permit visibility. Interestingly, I can extend that detail brush to touch the floor and ceiling, thus dividing the structural plane 'behind' it wholly in two, and vis is still blocked. I can extend it on a third side so it touches the next wall, reducing the structural plane to a tiny thin strip along the other edge, and vis is still blocked. So, if there's any fraction of a brush plane left in the world, it blocks vis as if the entire thing were there. As soon as the detail brush gobbles up the entire plane, though, it's gone completely and visibility is fully permitted. Theoretically, if the information of the original structural brushes was retained somewhere, could this be...fixed?
I've just disproved all of the above with further tests!
I tried to make a showcase map with one example of each detail brush, and rearranging the hallways broke the effect one way or the other. The original test was the one horseshoe, modified and saved and rebuilt, and my first run was with no detail brushes at all to verify that vis was blocked under normal circumstances, so the effect was real. It seems to only happen in a more narrow set of cases than we'd thought. Looking at how I've rearranged the map, the detail brush 'test chambers' are at the ends of little hallways now, and stepping into one fully closes off visibility of everything else regardless of detail brush use. I'm guessing that since there's a portal that's closed in all cases higher up the tree, that closure simply applies all the way down the branch into each test chamber and overrides any 'hole' a detail brush might make. I'll clean this map up and put all the test cases in it, and you can just noclip between them instead. :P I'm posting the link in 'Mapping Help' instead so as not to further hijack the OBJ2MAP thread for detail brush debugging.
Good info tho, thanks for doing that. So as long as some part of the original structural poly remains, VIS will be intact.
It does as long as you don't consume entire polygons from the structural brushes.
func_detail is still compiled into the BSP but it doesn't generate portals Use responsibly. :) func_detail gets "stitched" onto surrounding existing portals which take part in PVS, it just doesn't get computed in the first place. Maybe this explains "holes" and such things..
I was wondering if it is possible to revert process?
For example, user would be able to throw together rough prefab, convert to OBJ, import to modeling software and use it as a reference for exact size precision. Maybe modern map editors already able to do this, but as GtkRadiant user I don't have this option. Doom3 editor does that.
Use q1 to q2 mapconverter, should let you load in Doom3 editor, then export brushes as obj. Or maybe it's jusy ase..? well, what it does is export to a half-broken file in the obsolete DXF format, which Maya can in fact import, with difficulty and a lot of cleanup. Because Source.
Sketchup might load it too, but this is already a longer shittier tool chain than loading in doom3. Also you can set it to not output faces that have a certain texture on them so you can texture everything with skip or whatever apart from the visible faces and the output mesh is a lot cleaner
Well, that's what I would prefer to dodge - having a chain of tools [or overkill ones] for something that seems to be a trivial task.
Just tested it. Aside from inverted normals, gtkr1.5 brushexport2 works fine.
Still an extra link in tool chain, but at least it is something I have some experience with. If you want export all brushes as mesh with UV then yes, it should be fairly easy to do.
I'll update OBJ-2-MAP in a few days. ATM I'm adding classic format and valve220 + UV to one OBJ-2-MAP version, so you'll be able to choose. I believe I found a bug in the tool. Trying to send you an email, but server is rejecting it.
The error that the other server returned was: 550-5.1.1 The email account that you tried to reach does not exist. Please try Probably best to post the bug here, actually. Multiple people are touching the source code these days so it's more productive to make it public.
Since description page doesn't say that mesh should be 100% convex, thus I assume it is a bug.
Here are few meshes I experimented with: https://dl.dropboxusercontent.com/u/58150516/q1/test_obj.7z test_0 Worst case. Doesn't show at all in editor. For some reason I can't create new brushes after opening generated map. test_1, test_2 Only part of original mesh exist in resulting map. test_3 Fully convex. Works flawlessly. Default conversion settings used. GtkRadiant 1.6 Any additional info I can provide? You are right, unfortunately n-gons and weird faces will not work in OBJ-2-MAP. I have a plan to add triangulation for non supported faces. What do you think about this?
ps. thx for examples, it will help a lot Browsing around the internets I came across a thing, which led me along a train of thought that ended up here:
there is a workflow that I realise would allow to rip / export these maps. it is as follows: 1964 N64 emulator. add lemmy's gfx plugin. load quake64 export geometry to VRML convert VRML to obj in (insert modelling app) convert obj to map heck, this would even work with other n64 geometry. N64 Quake maps are just very simplified Quake maps. I'd say not really worthy of the effort to get it ported to PC. This is contrary to Quake 2 and Doom which were both different experiences from their PC counterparts, Doom 64 has already been ported to PC with Doom64EX and I think Quake 2 deserves similar treatment.
that's right. Quake 64 were simplified versions of the id maps. Doom 64 and Quake 2 were completely new.
Cut out areas in each map. I think the DM ones survived, apart from DM3, which I vaguely remember was cut completely.
Yes, the N64 maps were lower poly versions of the stock id maps, but even so that conversion pipeline you posted would be a horrible way to do it considering they were most likely in the same or similar quake
Did few more tests with geometry triangulated before OBJ export:
------------------------- 1 https://i.gyazo.com/b7aaee92102d303b106f224717330994.png Still doesn't show in editor. ----- 2 Tried to explode mesh to separate objects by planar surfaces and export as single OBJ. (Dragged apart just to demonstrate separation, actual export had it all composed to form original shape from first image.) https://i.gyazo.com/c68d21c69231501a34a7e4d1af420f90.png In editor each plane was enormous. https://i.gyazo.com/64b3cb526d1492c1e9c0e3cbf301c830.png I suspect brush[es] is too big to fit editor's working area every time I'm seeing nothing on map load, but can't confirm. ----- 3 Divided in 3 objects. Those 2 broken cubes in the middle is one obect. https://i.gyazo.com/1a73b829eca2febfd9ace8e7b11bcba3.png That worked a bit better - holes automatically capped, but middle part is missing. https://i.gyazo.com/4e2b52fe9bd44f5a929b83d8aa2d2058.png ----- 4 Same as before, but each broken cube is separate object now. https://i.gyazo.com/295ee6321b434b52dd0dbd8be3cad663.png Results in this: https://i.gyazo.com/1ad1233bd0ef52c2fddba2c1922a9f5d.png Cube parts go to "infinity". At least far beyond the end of editor grid. -------------------- OBJ files: https://dl.dropboxusercontent.com/u/58150516/q1/test_obj2.7z I doubt they're in bsp format. Even if they are, the rom dump process probably doesn't retain any semblance of a file format. It's probably the simplest way without actually reverse engineering the rom programming.
you could *try* and hope for some success with watching memory for bsp headers, it's just so unlikely though. In all likelihood the programmers stripped all superfluous data from the game to save space. True. Console games are generally munged pretty harshly to get into memory. Headers and such are right the fuck out...
DW
Try this one again: https://embed.gyazo.com/295ee6321b434b52dd0dbd8be3cad663.png But cap all the geometry in Blender so there aren't any holes. OBJ2MAP doesn't add capping geometry or do anything other than convert triangles to planes. You need to feed it valid Quake geometry. In other words, the cubes extending to infinity is totally expected
To see it in action, feed it a cube and look at the results. Then remove one of the cube faces, run it through again, and see what happens.
That should solidify what's going on in your mind. :) I believe they're their own proprietary format. Oddly when Quake was ported to Saturn, for example, it used the same engine as Saturn Duke and Saturn Exhumed...
Cool article on reverse-engineering saturn quake: http://www.richwhitehouse.com/index.php?postid=68
What confused me is that in some specific conditions it acts as if it had that functionality.
Specifically this https://i.gyazo.com/1a73b829eca2febfd9ace8e7b11bcba3.png producing that https://i.gyazo.com/4e2b52fe9bd44f5a929b83d8aa2d2058.png Capping aside, breaking geometry to group of convex shapes by hand, opens gate for human error. Not to mention might be extremely time consuming. From the top of my head - I can't imagine a good way to break inverted hemisphere to chunks of valid geometry. It's just the way of it. OBJ2MAP isn't doing anything hardcore magical
until you add it you're going to be fielding these concerns until the end of time :)
see: everyone asking sleepwalkr why their map leaks or whatever "in trenchbroom" re: "this producing that", the black plane on the piece on the right side extends to seal off the solid.
Capping aside, breaking geometry to group of convex shapes by hand, opens gate for human error. Not to mention might be extremely time consuming. Yeah, one possible way is build a bsp tree out of the concave geometry, which makes slices that gives you convex pieces. But the downside is it will probably make ugly slices that a human wouldn't choose. in convex shapes with gaps, every open edge will be extended until it intersects with something.
In case of cube with one side removed, all faces a parallel, thus continue forever. But say we remove top face of the cube and then scale up bottom face. This will produce a pyramid by extending faces until intersection point. For me this is magic! That kinda blows my mind and imagination goes wild. For example. Maybe I'm completely wrong here and think that easy things are hard and vice versa, but I'd guess that tool is already creating geometry that wasn't there in OBJ file and if it can detect intersection the same way it can detect the Alas my knowledge of magic is insufficient to imagine "perfect solution" for solving problem with concave geometry. 8/ "but I'd guess that tool is already creating geometry that wasn't there in OBJ file"
Technically, no. It's creating plane definitions in the resulting MAP file. The infinite geo and such that you're seeing is being created by the map editor you're loading that MAP file into http://panjoo.tastyspleen.net/rust/tutorials/brushcreate/brushes.htm
felt like reposting this again. You can make valid cubes by just having 6 triangles. You need those cutting planes or indeed it goes on forever. Once you get the logic its easy to build brushes. |
|
|
Post A Reply: |
|
| Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors. |