Reply With Quote
Hats off to you, this stuff is insane!
Update: long story short, i decided to resume work on this mission after all. not gonna withdraw the asset dump, but im going to hijack this thread to be a devblog for the mission from now on. starting here.
(ugh, why does this not allow anchor links anymore? just trying to link to something further down the page, but no....)
Original post:
its become clear to me that i will probably never have the opportunity to finish this mission, so i am dumping it all here. idk if much of the mission files themselves will be of value, but there are at least a bunch of technical innovations that may be of interest:
- the showpiece: dishonored2 "crack in the slab" style alternate world switching with inventory item to see through to the other world. uses a custom "periapt" osm that hooks the thief exe to do stencilling and a second render pass (as well as limiting draw distance to fog distance to improve render performance). status: works well, but a number of small issues mean its not production ready: video 1, video 2, video 3
- textures: a bunch of dirtified and moss-grown variants of core textures. one or two custom rock textures.
- (edit: ) models: a bunch of new models: ruined versions of stock furniture; a deco chandelier; an exploded vault door; a rope bridge; a sailboat; burial jars.
- (edit: ) paintings: a bunch of creepy paintings in the library: video
- swimming burricks: proof of concept of amphibious burricks. status: needs more work on swimming animations and preventing combat behaviours in water: video
- abusing the spider skeleton for lipsynced face animation for a giant stone head in the mission. too specific for this mission to be reusable, but a similar approach could have many other uses: video 1, video 2, video 3.
- (edit: second video) baby burricks: new skin for baby burricks with more fur and stripes, and new animations for hopping walks and rolling. behaviour scripting to follow mother, but divert for objects of curiosity; and startle reaction (toxic burp and run away) when surprised by player: video 1, video 2.
- rope and ladder experiments: moving ladders, not great. moving ropes, works well. antigravity ropes (attached to floor, floating up) also work great: video 1, video 2, video 3
- (edit: video) spooky compass. using scripts and tweqs to make a spooky alternate compass that opens an eye and looks around: video.
- wisp-powered-generator. alternate generator with removable power source based on captive wisps: video
- (edit: second video) using scripts to control post-process shader effects (toggling, adjusting strength): video 1, video 2.
the stuff:
- "furis, o anima" (codename 'dual') mission files
- most of the tech demo mission files
- sources for "periapt" osm
- sketches and notes for the mission, including notes relating to periapt osm development (dropbox)
- ghidra files for peripat osm development (dropbox)
the two items hosted on dropbox are probably less permanent links than the github ones. and the ghidra files will only be of interest if you wanted to take the periapt osm source code and do something more with it.
random extra: i had half-done an update to "making a profit" with a toggle-able commentary mode and behind the scenes stuff. but that will probably never see the light of day either. but theres a rough draft of some of the commentary: video
Last edited by vfig; 31st Dec 2022 at 12:31. Reason: now its a devblog, sue me if you dont like it
Hats off to you, this stuff is insane!
I had a similar idea to this, but it didn't have the dynamic view thingy, that's really clever.
This looks great, I like the library architecture, hope someone picks this up to finish it
Thanks for your effort with these vfig. That big face animation is quite mind bending.
Very impressive stuff, sad to hear it won't get finished!
The Keep for Thief 1 and 2 FMs, Shadowdark for Thief 3 and Dark Mod FMs
A lot of these fit into my mission story which has the player in very different environments moment to moment. You stuff will help here a lot. I will try to modify enough as to not conflict with anyone else's ideas.
Also, I've been watching your channel and have to say how impressed I've been on going from "interested" in making things for Thief to outright putting your mind to it, and trying it out. Bravo on this work.
addendum: although i cant justify putting more days into this myself anymore, if anyone does want to use any of this in your own missions, i am happy to explain any of the workings and maybe do some small tweaks here and there if needed. catch me on discord (vfig#2312) if needed.
Sorry to see this extraordinary work going unfinished. Hope folks will make some use of it and maybe even somebidy feels like finishing it at least close to your visison. Thanks for sharing this with us.
Are you done with just this project or Thief and Dromed in general?
If you tell me you find Dark Engine and Dromed somewhat limitting for your magic and trickstery, I won't blame you!
ideally, neither! if i could afford a few months and a few grand, i would love to throw myself back into this and finish it. but thats not in the cards. and i cant work piecemeal, my brain only lets me go all in or all out. so, for the present it must be all out.Originally Posted by PinkDot
and its definitely not about disliking dark. it has limits, of course; and one aspect i enjoy of working with it is working around its technical limits (the visual arts limits are harder, but also not really my field). but honestly for creative expression through level design, dark engine is far better than any other ive used—its an absolute joy. source engine is a close second; doom3 engine wasnt bad. everything else ive tried (especially generic engines like unity and unreal) fall far short of that ease of expression. i havent yet tried source 2, it sounds like a solid contender; but hey, i dont have the practical opportunity to dive into that either.
ah fuck it
ever since i went to collect this stuff to dump it here, it has got back in my head and wont leave
guess i should try to finish it before i die, huh
I suggest focussing on what parts help to tell the FM's story and ruthlessly cutting out the rest. Beware the sunk cost fallacy!
Last edited by R Soul; 10th Dec 2022 at 15:56.
Yeah I'm watching your lets plays. It's hard not to get some inspiration from that too.
oh sure, but scoping has never been the issue. never had a problem cutting things that are better off cut.
yeah, thats why when i put the fm on the shelf, i had to stop playing other fms too.
dec 11-21, 2022
the most obvious work needing to be done, and easiest to pick up after a long time away (the last change had been on feb 19, 2022) was detailing. while the exterior of the mansion had been fully detailed (though not yet lit) a long time back, only a handful of interior areas had been.
so i spent the first week and a half detailing and lighting the entire unruined version of the mansion. here are before and after shots of the east wing entrance hall:
A: before/after
B: before/after
C: before/after
Last edited by vfig; 31st Dec 2022 at 10:46.
dec 21-30, 2022
grief in stages: after the detail pass on the mansion, the mission hit 78238 raw cells, and would not even portalize! this was a big surprise to me, because its not all that big, even taking into account the three copies for the different time periods. and i had reached this particular layout after cutting down in size twice from the original blockout. but what can you do?
i started out by bargaining: if i amputated whole sections of the mansion, could i save enough cells to get it to portalize again?
deleting the dining hall saved ~3000 cells (as measured when portalizing just the nonruined mansion section):
deleting the colonnade saved ~1500 cells:
both were significant losses to the visual appearance of the mansion, but neither loss would be catastrophic for gameplay. and even then, the savings were not looking significant enough to save the mission: bearing in mind that the ruined version of the mansion still needed much of the interior detailing brushwork to be carried across and adapted into ruined form, which will eat more cells.
i almost despaired entirely again. but then decided to move onto the denial stage. i would have my cake, er, mansion and eat, er ruin it too! back in 2021 i had written a blender addon that would import the worldrep of a mission (including lightmaps, so that unlike the newdark dromed's .obj export, the exact in-game appearance of the mission could be replicated); and that meant i had some understanding of the .mis file format and how the worldrep was stored.
(the worldrep, if youre unfamiliar with the term, is the output from portalize/optimize. its a bunch of cells—convex polyhedral volumes—that make up the entire space of the level, together with the portals that connect them and the polygons that are rendered to the screen. in addition, the worldrep also contains a bsp tree of the level that is used for spatial queries and physics and stuff. and the worldrep also contains some extra information thats used only by dromed to identify which polygons were generated from which brushes, which is needed so you can select brushes in its 3d view.)
so i came up with the idea of writing a tool to merge the worldreps from multiple .mis files together into one. after all, each of the three parts of my mission, when isolated by an area and optimized, was around 6000-8000 raw cells, and optimized down to 2000-3000 cells. the three parts of the level are completely isolated, so i wouldnt need to do any shenanigans around changing cell faces into portals or anything like that. and the bsp tree would just need to get a couple extra nodes at the very top, with each of the input .mis's bsp trees as separate branches below. in theory, pretty doable.
well, progress on that was slow. the .mis format—the worldrep specifically—is only partially understood as far as public knowledge goes. many others have done work with it before (e.g. for the OpenDarkEngine project, and PinkDot's editor). and with the t2 source code to read, the olddark worldrep structure was at least knowable in all its details (though understanding it all is a different story!). newdark though made a number of changes to the worldrep data, only some of which are known. outputting a non-crashing .mis is going to require figuring out those unknowns, too.
as of dec 30, after some false starts, i had my code successfully reading both olddark and newdark worldreps entirely. but hadnt yet made a start on writing it back out unchanged (straightforward) or the actual merging (the hairy part with lots of exciting crashes to come).
dec 31, 2022
understanding binary data and writing code to manipulate it is a much more mentally intensive task than faffing about in dromed, and i struggle a lot to find impetus to work, and to keep focus when i have found some. so the going has been slow. i have been playing more fms in the past ten days, which, though it eats a lot of time, is better than anything else i have found in getting my brain into gear to actually work. and hey, that gives me more lets play episodes to post on my youtube channel.
today while finishing up the last couple objectives of an fm, and with convex cells and bsp planes still floating around my mind, i wondered what would happen if instead of stacking the three parts of the mission vertically, one directly above the other, i offset them horizontally? this would prevent the vertically-oriented planes of the brushes in one area being shared with the correlated brushes in the other areas, which—… well, it would definitely have some impact on the csg process, though exactly what wasnt obvious.
but it is a trivially easy experiment to try, so. this is the vertically stacked layout that wont even portalize:
then shoving the top and bottom layers over in X and Y to remove the overlap… resulted in a raw cell count of 69091, csgmerge input of 32521, and optimized output of 8308 cells. it actually portalizes again!
this is good news for the mission—i might not need to do any fancy merging shenanigans now, together with the awkward workflow that would need (working on the merged result would be kinda like working with a stripped .mis, where only objects and maybe lights can be changed). but bad news for the merging tool: maybe i wont need to write it after all??
well, im gonna keep trying a few more variations in laying out the three parts now, and see how they go.
Good to hear you managed to pass through the block in such a simple (yet not obvious) way!
I do think however that the idea of merging multiple worldreps is interesting enough and maybe worth getting back into at some point.
Over last couple of days I managed to decipher the rest of WREXT chunk. That includes CSG Internal database and additional New Dark arrays, which you may not encounter unless you mess around with Zones. Let me know, in case you're interested.the .mis format—the worldrep specifically—is only partially understood as far as public knowledge goes. many others have done work with it before (e.g. for the OpenDarkEngine project, and PinkDot's editor). and with the t2 source code to read, the olddark worldrep structure was at least knowable in all its details (though understanding it all is a different story!). newdark though made a number of changes to the worldrep data, only some of which are known. outputting a non-crashing .mis is going to require figuring out those unknowns, too.
i havent given up on the merging idea yet—for one thing, even though the mission portalizes again now, there is very little headroom, and the ruins still need a lot of work on them. so the merge might still be necessary.
and yes, i am very interested in everything else youve figured out about the .mis!
jan 18, 2023
almost three weeks and a lot of distractions later... i finally got back to the merging tool today, and wrote a first draft of the worldrep merge program: just enough to see if the whole idea can actually work.
to test it, i made two single-brush maps, not far off the simplest possible. the first has a six-sided cylinder above the zero plane:
(why i am using olddark dromed will become clear soon.) and the second, a boring cube below the zero plane:
once i had fixed a few silly typos in my program—oh, sorry, i forgot to introduce it properly! it is a program that does things to .mis files, so quite obviously it is called misdeed.exe—aaaanyway, got it compiling and fed it the top and bottom .mis files, and it duly spat out a result.
next step is to load up the result in dromed: and of course dromed immediately crashed! i fully expected this: the worldrep is complicated, and there are little bits of it we dont quite 100% understand yet, and also i took a few possibly unjustifiable shortcuts for the sake of the first draft. thankfully debugging what went wrong was made about ten million times easier because by luck a certain source code repository happened to have a build of dromed in it with its .pdb! and so:
(for the non-windows-programmers, a .pdb is a file full of debug information about a program: its so that when the compiled program is running, visual studio can know what the function and variable names are and which source code files and line numbers correspond to any part of the .exe). turns out the source code files in the repo arent a 100% match for those that this dromed was built for, so the line numbers are a bit offset (visual studio thinks the program is at the line shown in green; but its actually at the line i highlighted in blue a little further below). but close enough, and the local variables here all match up, and it meant i could instantly understand what my program had done wrong to cause the crash. so i fixed that problem, and ran my program again. and loaded the output into dromed, fully expecting another crash. but:
it worked?!? im showing the game mode view here, because my first draft isnt copying the brushes themselves over, so the editor view is less than helpful. but in game mode, you can see both cells are there! i can fly into either one, and everything about them works just fine! i am stoked.
Last edited by vfig; 20th Jan 2023 at 05:17.
jan 20, 2023
woke up this morning with the joyful realisation that for this mission's needs, i dont need my merge tool to be smart at all. each of the pieces i am merging is taken from the same .mis anyway, so i only need to merge the worldreps and can simply copy all other tagblocks from just one of the files into the output. i shouldnt need to merge texture lists or anything like that.
(it would be nice to merge the "csg data" at the end of the worldrep that dromed uses for e.g. hit testing polys to find brushes. the game doesnt need it, so its not vital. maybe i will implement that, i will have to see what my workflow feels like without it.)
so lets skip the boring incremental tests and see what happens when i throw some of the real mission data at it!
well, that looks promising… lets go a bit closer?
ah. ahaha. yeah no. something is quite wrong.
also monolog is yelling at me about various objects (including the player!) being outside the world. and sure enough, if i unfly, i fall right through this terrain.
okay, back to the boring incremental tests, lets try and find the fault.
jan 26
the complexities of the worldrep merge have temporarily defeated me. something is going wrong that i havent been able to debug yet: olddark dromed simply doesnt render the problem wr, while newdark dromed crashes. normally a crash is the easier kind of problem to debug, because it gives you a definite starting point for investigating; but the lack of symbols for newdark dromed makes it hard. msvc isnt the best debugger when you dont have source code: either it doesnt have the tools to annotate the disassembly to keep track of things—or if it has those, theyre hidden enough that i havent found them. but i dont at the moment have any better debugger to use.
so for now i set that aside, and got back to the ordinary business of dromeding: the ruined version of the mansion still has only placeholders for most interior rooms, so i have begun the drudge work of copying over the detailed rooms from the unruined version, in preparation for utterly trashing them.
i started out with the "conservatory". but instead of just copying it as i should have, i looked at it and decided i didnt like the layout. it felt too bland:
so i reworked it to have the secure room in the center instead of in a corner. is this layout better? for a typical thief mission, i would say yes, it makes traversing the room more interesting. for this mission, im not actually sure! but for now the new layout is staying. what do you think, is it better?
the other significant change to this room is the planters themselves. up to now they had been made of brushwork. as part of a general effort to reduce cell counts, i decided they would be better off as objects, so i made a model for them. one downside of an object is it can only have a single material, so while the planter objects are wood, i have second, unrendered object on top of each that has the dirt material.
the room still needs plants and AIs and stuff, but that will happen in a later detail pass.
VFIG I am not sure if you read this whole thread yet but it was a life saver for me on cell count https://www.ttlg.com/forums/showthre...uce+cell+count
I believe it was this one that talked about how the order of your giant air brush you're populating matters. I think there is a benefit to making sure it is moved to the earliest possible in the time. But don't quote me, I've suspending my building as I am taking a break and it's been a long time since I had to read it. But it's worth the read and whatnot, hopefully that part comes up sooner than later. Cheers.
yes, ive read that one, and most if not all the old threads about optimizing cell counts. but right now the low hanging fruit in my mission has already been harvested. there are a few smaller places where i could mess about with brush timing and probably get some small benefits, but im pretty sure reducing detail in various places is going to be necessary—at least if i cant get the worldrep merge working when im ready to go back to it.
Compositionally, the first conservatory is more interesting. I would leave the secure room in the centre but do more interesting arrangements than a circle with the planters. The new layout also looks like it'll be easy to cheese AI with if there's no gaps in the ring of planters.
It's a good model - don't forget you can always convert worldrep into models via the export tool, useful if you have any complex brushwork left with minimal collision/lighting requirements.
Posting Permissions
