motorsep
-
Posts
913 -
Joined
-
Last visited
-
Days Won
2
Posts posted by motorsep
-
-
Deferred Rendering is supported on any dx9 shader model 3 and up GPU's, does are considered very old cards by now, and any dx10 card can be bought by less of 50€ nowadays, no reason to lock a engine progress because of ancient hardware. Btw Tr3B's shadow maps aren't more performance heavy per ce, is just that because Doom 3 was not made to support shadow maps it is not optimized for it, and so for example many lights that were not casting any shadows on the vanilla engine become shadow casting lights with the shadow maps, for example all lights behind alpha mapped surfaces. Is totally possible to have a performante game with shadow maps if you know how to optimize them.
GLQuake was not designed for anything modern and yet DarkPlaces has shadow mapping and deferred rendering and real-time GI, and it performs way better than xreal/rbdoom3bfg when it comes to shadow maps. It's an excuse for not optimizing shadow mapping implementation in RBDoom 3 BFG. Instead of going "because I can!", it would be much wiser to take DarkPlaces' shadow mapping and implement that.
I can play Crysis 3 with quite decent quality on my rig, and Crysis 3 has a way more taxing graphical features than RBDoom 3 BFG that only has shadow mapping. On some levels in RoE all timers go red. It absolutely has nothing to do with original engine and it has everything to do with how new stuff (shadow mapping) was implemented.
Either way, the point is that when you begin supporting wide range of hardware and different rendering paths, you get a mess in the code. You need an experienced dedicated programmer (or a few) to support it, not to mention to engineer it to be fast and stable. Once you begin pulling pieces from different forks into one, without having experienced software engineer who has at least 10 years of experience hands on with game renderers, you will quickly find yourself in a world of pain.
Does TDM team really need/want to be in a world of pain? What TMD really needs is GLSL back-end and GPU skeletal. That alone will boost fps and that's not something crazy to implement. Threading, deferred rendering and shadow mapping are much harder to get right (fast and stable).
-
Deferred rendering also means that only certain GPUs and up will be able to play the game. Older (but still very capable) hardware will be cut out.
Not to mention that people with lower VRAM bandwidth will be out of luck too.
Tr3b's shadow maps are _slow_ and VRAM bandwidth consuming making Doom 3 BFG unplayable of the hardware that plays Doom 3 BFG vanilla at 50-60 fps.
-
Yeah, with id software themselves violating the silhouette parity rule this seems to be a totally nullified excuse.
I'll bet dollars to donuts that this is more related to Carmack's sour grapes about the leak of the Doom 3 demo by an ATI employee
and ATI's "trueform" tessellation tech...
Well, for once ETQW wasn't ID's baby. You are missing the point. If you tessellate model, then silhouette becomes too complex for shadow volumes. I don't know if you can selectively tessellate model, per surface.
-
Several games use it. From tomb raider to online games like TSW. As for the shadows that's right We'll need different shadow models to be tessellated along with the mesh. I completely agree with needing very good programmers for it. As for mentioning DR i did so because is based on doom3 and even if i knew the limitations of doom3 I'm not sure if they stay with DR or if they are changed. I don't know how much customised Dr is already or even how much customisable it is.
DR is DarkRadiant, a level editor that has no dependency on graphical features used in a game, whether it's Doom 3, Quake 4, The Dark Mod or any derivative from those engine (as long as core framework doesn't change).
So even if Doom 3 derivative engine would be CryEngine 3-like in graphical features and appearance, that wouldn't affect you making maps for it using Dark Radiant
-
John Carmack gave a rather weak rebuttal against implementing tessellation. He said that it would cause the model
silhouette to differ from the shadow silhouette. Since we already use low-poly shadow meshes this justification is even
weaker...
You can have shadow mesh, like in ETQW.. It won't match visual mesh, but who cares!
-
What games use tessellation ?
Does Dishonored use it? Or Deus Ex HR ? Or Wolf TNO ? If they do, I probably had it off for performance reasons and not having it didn't really diminish quality of visuals and overall presentation of these games
Somehow I think TDM shouldn't bother with modernizing the engine, because A. engine is old and would require too much refactoring, B. savvy graphics programmers are so scarce, that having half-savvy programmer digging that deep will result in unstable, inconsistent and poor performance (and constant breakage on various hardware)
I think adding maybe extra shader effects that don't require engine overhaul, and poking at better visuals (keeping it stylized, getting away from photo-realism) is a way to go.
-
Oh well. It's either Blender, or writing/fixing ASE exporter for Maya
-
Use Blender?
-
Ah, so no one has ever tried compiling it with 2013.. Interesting.
-
I use ASE/LWO exporters in in both cases it's one-click-export. Just name Blender material exactly like your Doom 3 material and that's all. No need to edit anything after export (LWO can't be edited anyway).
So it's just a matter of the exporter for any 3D package of grabbing 3D package's material name, and writing it into appropriate place in the ASE/LWO/OBJ in appropriate format.
-
So recently someone tried compiling our engine, which includes same MFC-based tools as Doom 3, with MSVC 2013. It was not possible as MFC was dropped from MSVC 2013. Using MFC hack (repackaged standalone MFC that allows compiling Doom 3 and derivatives with MFC tools using MSVC 2010 Express) doesn't work either with MSVC 2013.
What MSVC version do you use to compile TDM with tools ?
-
FBX SDK is no open source as DR/TDM, but it has docs and ok interface. There are a lot of people working with it, including Epic (UE4). UE4 has full source code accessible, so if someone would be determined to make it happen - there is no issue doing that.
-
Someone needs to make FBX > LWO && ASE && MD5 converter
-
Maya doesn't export into ASE ? I am betting it's not that hard (for a programmer) to write Python script for Maya to export into ASE.
http://www.creativecrash.com/maya/plugin/ase-file-export-for-maya
http://udn.epicgames.com/Two/StaticMeshesFromMaya.html
-
But does the engine "understand" OBJ? Vanilla Doom 3 doesn't afaik.
-
But I'm not pushing against it, I just want to understand, I feel so stupid for not getting the point of it I just want someone to explain
It's a matter of preference maybe? Original Doom3Edit has BSP menu to build map. And you can still open game instance and compile map from the console, like you have been suggesting.
I am just asking about possibility. I am not pushing for it
-
@AluminumHaste: Well, all I can say is if you don't get it, why you keep on pushing against it?
-
Edit: But how do you make the engine exist after the dmap? With "+dmap mymap.map" it stays in the console after it is done. With autocommands.cfg, it can exit automatically afterwards.
Yeah but that still runs Doom3/TDM, then calls DMAP. I though the whole point of having dmap options in DarkRadiant would be to be able to DMAP without running the game, maybe just have a command prompt/terminal window with DMAP output, which sounds like what Greebo was working on.
And besides, kind of pointless, if you're working on a map, just bind a key to Dmap <mapname> ; quit, then run TDM and press F11.
Why would you want to compile map, and not even check if it works?! o.O
The point is that you can run a process instance minimized, and quit after it's done. So initial process instance would run and stay running. If you build map second time, a new instance would run minimized, quit after building is done and you just reload map in the original instance.
Monitoring dmap as it goes is pointless. You can dump console output into log file, after dmap is done, and see what's in it.
Otherwise, yea, I can just press arrow up to bring previous cmd while in the game's console and compile it :/
-
Swift Mazes: http://forums.thedar...__fromsearch__1
autocommands.cfg is executed by TDM, so DR can use it for dmapping a map without TDM first getting support for command line arguments (which might have been implemented in the meantime, I don't know).
TDM uses Doom 3 engine. All cmd args are already there. All that is required is to run external process with cmd args, that would be set via Build menu gui of DR.
I've done this for my Doom 3 BFG mod launcher using Qt5 frameworks. wxWidgets have the same capacity.
-
That is also how Swift Mazes does it. A "dmap only" can be specified via the autocommands.cfg file already.
What is "Swift Mazes" ?
Also, what does autocommands.cfg file have to do with DR ?
-
I had plans for that in 2012, yes. I was at about 70% done porting the code from the engine into DarkRadiant (the code is still there), but it didn't work out due to slight differences piling up and I seem to have completely burnt out on that task. I'm not going to touch it again, the cost benefit ratio is too high.
You are overthinking it
All you need is to run a process from DR with cmd args. There is nothing need to be ported from engine to DR. The build menu would simply allow to specify .exe, and specify cmd args (all wrapped into nice GUI).And when designer selects an option from Build menu, DR will run detached process:
<executable file> +dmap [dmap's args] <map file> +map <map file>
-
Ah, sweet. I will use manual method. Thanks!
Btw, I have been wondering, but always forgot to ask - are there any plans bringing over Build menu? (to run dmap with cmd args and/or start the game with freshly compiled map)
-
When switching back to 1.8.1, either keep a backup of your personal input.xml around for restore or edit the Keyboard shortcuts in 1.8.1.
I can't bind Esc in 1.8.1 either. When I go into Menu > Edit > Keyboard Shortcuts and try binding Esc to the "UnselectSelection" command in 1.8.1, it doesn't get bound :/
-
Yes I do this as well, have been since version 1.4. So not having this function is a showstopper for me.
The worse thing is that after I installed 2.0.0pre*, I no longer have Esc deselecting in 1.8.1, since I bet 2.0.0pre* overwrote old profile. I can obviously bind Unselect (is there such shortcut?) to a normal key, but then it's no longer standard way of DarkRadiant and I need to train new muscle memory
Wishlist For Darkradiant
in DarkRadiant Feedback and Development
Posted
What's in the white papers on deferred rendering and shadow mapping, is not what they have in UE4, CE3, Source 2, etc. Btw, since UE4 source is available, I wonder why no one cares to learn from it o.O Even Epic said that they encourage people to learn from the source.