Source Filmmaker

Source Filmmaker

Not enough ratings
Scarlet Monastery
   
Award
Favorite
Favorited
Unfavorite
Universe: Original IP
Model
Models: Architecture
Tags: SFM
File Size
Posted
Updated
7.057 MB
14 May, 2016 @ 2:57pm
15 May, 2016 @ 5:03am
2 Change Notes ( view )

Subscribe to download
Scarlet Monastery

Description
=============================================================================
A model from the "From the Archives" series.

What does "From the Archives" mean? These models are ported from various games and appear on a private project repository that used to be public. These models are often not polished, are missing features and are usually not finished.

=============================================================================

There's a lot of unpolished stuff that I'm aware of but I can't really fix those. This thing is EXTREMELY MASSIVE so you will have to either scale it down or use a very large void map.

Please don't complain about the low texture resolution, It's not possible to fix that due of Source Engine limitation. A lot of experimentation has went into this due of the Engine's limitation and the tools being either very old or incompatible, so this is how far I got so far.

If you want to donate, you can do so at http://heykidwannayiff.com/

UPDATE:
Textures fixed by BlueFlytrap
http://steamproxy.net/id/blue_flytrap_998
Now it's pretty tiny

Includes:
thunderysteak\scarletmonastery.mdl
12 Comments
BlueFlytrap 15 May, 2016 @ 11:20am 
For that model in particular I used cra0kalo's studiomdl. Altered to bypass a few things but is nowdays difficult to set up.

I say nowdays as the go to method was to use the dota2 bin; but that branch no longer exist with the game's update to source2. Not sure how one would go about it at this time.
Temporaryalien 15 May, 2016 @ 6:25am 
Yes more WoW content for SFM
Thundery Steak  [author] 15 May, 2016 @ 4:35am 
Thanks. Can I ask what mdlstudio compiler you used? I'm planning to port wintergrasph next but I'm having the same issue with the material count. This time I'm gonna attempt to push metal to the pedal with the quality and pray for not hitting any engine limits
BlueFlytrap 14 May, 2016 @ 5:40pm 
{LINK REMOVED}
Thundery Steak  [author] 14 May, 2016 @ 4:47pm 
BlueFlytrap 14 May, 2016 @ 4:43pm 
You could toss the files my way and I could give it a shot. While it doesn't sound like there are any errors on your part I do suspect part of the problem may be on your end.
Thundery Steak  [author] 14 May, 2016 @ 4:33pm 
I did not say that UV maps are an engine limitation, just that it's very time consuming. The material count is the limitation. I'm using SFM's own StudioMDL. It errors out complaining that there are more than 25 materials and stops compiling. VTFEdit doesn't work even with BGRA8888 or BGR888 format
BlueFlytrap 14 May, 2016 @ 4:18pm 
No. I know exactly what the sfm's limitations are.

Tedium in regards to uv maps is not an engine limitation.
You can compile multiple smd with multiple model commands in the same qc.
Which mdlcompiler fails to go above 24? Which one you use matters.
Don't dxt compress absurdly large textures. Leave them uncompressed in a format such as bgra8888 or bgr888 so you can actually save them. Even then they might not work so refer to my previous point of just merging similar things.
Thundery Steak  [author] 14 May, 2016 @ 4:00pm 
Editing 50 UV maps and textures by hand would be way too much work and it would be very time consuming. I never heard about compiling multiple models with a single QC file, there's no documentation on that on the Valve wiki. The MDL compiler refused to compile anything with materials above 25. VTEX and VTFEdit would crash with any image above 4096 x 4096 with nvDXTcompress crashing, that's why it had to be downsampled.

I'm pretty sure that you got the limitations wrong for at least the SFM's branch of Source Engine. Newer branches of Source (Portal 2, CS:GO,...) will have different limitations.
BlueFlytrap 14 May, 2016 @ 3:53pm 
Would probably have been way more efficent to merge similar materials into their own texture and uv, such as all the transparent bits being one, rather than merging everything.

Second. You can get unreasonably high poly models compiled by splitting into separate smd and compiling them together via the qc. If that doesn't work you can always make separate mdl to merge at runtime.

Third. The limit for materials is 64. The compiler themselves are usually limited to 32 with one exception. Even then, it's very rare anyone hits it even with excessive material use.

Fourth. You can have as many 4k textures as you want so long as the program itself does not run out of memory. As such mipmaps should probably be disabled to save as much as possible.