Anyone know what TDM FM this is? (screenshot)

[Goldwell]

So I was searching Google for The Dark Mod today and I came across this incredible screenshot from a mission

 

 

But the article doesn't mention what FM this is. The full article is here https://teksyndicate.com/news/2013/10/09/dark-mod-v20 but I would love to know what FM this is as it looks incredible.

[Airship Ballet]

Pretty sure that's either Skyrim or Thiaf. They both look very similar at night when the former is heavily modded. Looking at the textures I'd say Thiaf. It's not TDM anyway =P

Edited March 30, 2014 by Airship Ballet

[plotzzz]

Thief 4?

[Vae]

This is not from TDM or NuThief...It is from Paul Mader.

[Airship Ballet]

Huh, seems a fair few articles are nabbing his pictures without credit:

 

http://gamingbolt.com/top-5-features-thief-4-should-borrow-from-dishonored

[Goldwell]

This is not from TDM or NuThief...It is from Paul Mader.

 

Thank you!

 

And that is weird this image is being associated with TDM but eh

 

Also i'm a bit sad this isn't a playable mission. It would be nice to have some Thief maps on the Unreal Engine though, they seem to both compliment each other quite nicely.

Edited March 30, 2014 by Goldwell

[Vae]

Thank you!

 

My pleasure...

[RJFerret]

Make it?

 

We've got those window prefabs, although those half-timbers aren't plausible construction (some beams are perpendicular to the weight load) so you could do better, and the ground is boringly flat, the tree is very impressive, although the roots meeting the stones bluntly are rather unnatural, while the roofs are straight/featureless, you'd hopefully add more interest to areas other than the focal point.

 

But realize also it's designed to be a 2D graphic, with a single focal point following the photography rule of thirds, and lines leading the eye in (looking at the other works, they are all designed that way). So unless you match that style of lighting and fixed camera position, from other angles it will look just like our regular missions.

[demagogue]

The modeled func_stats make this screenshot stand out, basically everything that isn't a rectangular box. We could do a few things with patches maybe, but even that would be so-so and it really calls for modeled architecture all around. We've had a growing mantra around here to get mappers to start modeling func_stats more too, but it's easier said than done!

[Atheran]

The modeled func_stats make this screenshot stand out, basically everything that isn't a rectangular box. We could do a few things with patches maybe, but even that would be so-so and it really calls for modeled architecture all around. We've had a growing mantra around here to get mappers to start modeling func_stats more too, but it's easier said than done!

 

And func_stats is what exactly? For the noob here that is already thinking of modeling some architecture....

[Jesps]

func_static are basically entities that do nothing much other than being ... well static. You can do stuff like turn shadows or collision off.

http://wiki.thedarkmod.com/index.php?title=Performance:_Essential_Must-Knows#func_static_v_worldspawn_Brushes

[Atheran]

So basically the static models or assets or...props, however you wanna call them? from rocks and boxes to houses? Sorry for the noob questions but after many headaches with the wiki I still can't really see the difference between models and brushes in many situations and this one is one of them.

[demagogue]

They are models. Func_stat is just the entity type in the game (other entities can use models too, eg AI). Like Jesps said, they're entities that are just static, so architecture is a good us for them, and yes, the other props and such you mentioned.

 

The main difference to brushes is they don't seal the void or portal areas (leafs). So you put them over brushes, not replace them. Also brushes are usually simple blocky shapes. Func_stats are for decorative or curvy work. In fact, it's good to convert small detail brushwork into func_stat, turning them from brushes to models.

[Atheran]

Great! Two forum posts clears out a week of frustration!!! Thank you

 

Now to the point. What architectural models you need worked on? We need the existing models reworked upon or new ones? We can take this to pm's instead of hijacking this thread by the way. Not sure what the silent rules are in these forums. Or take it to my thread so I have everything, I plan to work on in one place.

[RJFerret]

Note also models can't be edited or have their textures changed in DR (aside from swapping for another premade skin), while func_statics can. This is why architecture isn't typically modeled, as your don't need sub-grid size details, but do need to match size and textures and be able to adjust and change them readily.

[lowenz]

Got a crazy idea: what about asking famous mappers (like Paul Mader) to challenge each other in a TDM FM layout? Sort of Royal-Pro rumble with TDM team as judge.....

Edited March 31, 2014 by lowenz

[Springheel]

What architectural models you need worked on?

 

What we really need are the highly detailed pieces that are hard to make with patches. Detailed door and window frames (that can easily have brush doors/windows placed inside). Sophisticated door handles. Things like that.

[Atheran]

Note also models can't be edited or have their textures changed in DR (aside from swapping for another premade skin), while func_statics can. This is why architecture isn't typically modeled, as your don't need sub-grid size details, but do need to match size and textures and be able to adjust and change them readily.

 

I was mostly thinking of converting .ase files to .obj import them on Maya or Max edit them and then export the edited model to .ase and back into the DR. Of course changing dimensions is not allowed as it'd break existing maps and offset any textures. In any minor details I could edit the texture files as well and reimport them in DR. To my understanding without changing the file names if done correctly the mapper only need to reexport his map to have these changes take effect. On the other hand making some new more detailed tileable/modular architecture models doesn't seem a bad idea to be honest. Altho' if someone wants to upgrade his map with them he'll need to remake almost everything which is bad. It'd add variety tho'. And even make it easier for mappers to create new maps with way more variety in buildings or facades.

 

What we really need are the highly detailed pieces that are hard to make with patches. Detailed door and window frames (that can easily have brush doors/windows placed inside). Sophisticated door handles. Things like that.

 

Doors/window frames/door handles are not hard to detail. The problem is the resolution limits. I could for example make a handle or a window frame in Maya, transfer it to zbrush to add ornate carvings on it as well... But limiting the polycount to 1k for example means I'll have to transfer them ingame with textures/normal maps. With a 512x512 limit on textures I doubt any such small details will be visible. I could always try that of course but, is that 512x512 texture limit an engine limit? Or an agreement between developers/mappers so it won't eat the FPS? In case it's not an engine limit, while it's a bad idea to spam such textures across the map we could have some so the mappers could use in places they really want to be extremelly detailed.

[Springheel]

But limiting the polycount to 1k for example means I'll have to transfer them ingame with textures/normal maps. With a 512x512 limit on textures I doubt any such small details will be visible.

 

A 512x512 isn't a hard limit, though only highly detailed objects need to have larger textures than that. We try to re-use existing textures whenever possible, as it saves on file size, loading times and drawcalls during play.

 

Here's an example of what I meant--the stone window and door trims are models. That can be done by patches but would take a mapper quite a while to make. The window and door itself can be selected by the mapper. They're obviously not very detailed, but that kind of thing is highly useful.

[rich_is_bored]

These kind of objects are background noise in a much larger composition. They aren't meant to be the focus of attention. If you view your objects in the proper context you might find that they don't look as bad as you think.

[Atheran]

I won't even try to understand what you mean by patching But I get your point about the models. Question is... We want new ones? Or the ones we already have more detailed? In either case may I have a list of wanted models so I can start working on them? Or I should start exporting every window/door frame, door handle etc from DR?

[Springheel]

I'm not quite sure what you mean by exporting from DR. I assume you'll use your modeling software to create an .ase or .lwo file, which are the two formats supported by TDM. You should probably just pick something and go through the entire process of getting it game-ready so you get a chance to learn the entire process...weren't you working on a desk of some kind?

[Atheran]

I mean to get the .ase files turn them to .obj and work on them. Then export the .ase and get them back into DR with the same name etc. Just updated. And yes I was on that desk but I have some technical problems with it Until I fix them tho' I can help with some work that people want to be done.

[nbohr1more]

This is an unfair comparison. Unreal Engine 3 is just better suited for those scenes than TDM.

 

If people want this level of detail to be possible, we need to be more aggressive about recruiting rendering engine

coders. Just using better modeled scene geometry wont give you parallax mapped surfaces and wont afford you the

polygon budget seen here.

 

http://3.bp.blogspot.com/_5aupA7xWq84/SeYb9TJ1m6I/AAAAAAAAAEU/ZLkbfiU2Jgg/s1600-h/Take6.jpg

 

If you want stuff like this in TDM and want to be able to "play it" we need engine improvements. You could probably

make a map like this which would run OK on high-end hardware but then you've lost your already sparse player base.

 

Frustratingly, it seems that Doom 3 BFG could probably do scenes like these at decent framerates... but only a select

few coders seem to know how to port the BFG renderer over and the one coder who has done it is keeping his work

under lock and key until his "commercial project" ships...

 

Yes, we can always just bump the base asset fidelity as time goes by since hardware keeps getting better but that has

the downside of never growing your player base because you're always cutting off your low-end segment. Commercial games

do this to some degree so it's not an unreasonable practice (I think even HL2 dropped some older hardware support) but

one of the persistent complaints about TDM has been it's "high system requirements". These complaints have been fading

as hardware improves over the years but a change like this might re-awaken that nuisance. Caveat emptor.

[Springheel]

I mean to get the .ase files turn them to .obj and work on them.

 

What .ase files are you talking about?