HOME | DD
TSelman61 — Hitman 2016 - Absolution Suit
#2016 #3d #61 #blender #ego #hitman #im #lazy #model #suit #ts #unknown #xps #xna #xnalara #6 #tselman61 #downlaod
Published: 2018-07-17 01:06:55 +0000 UTC; Views: 12403; Favourites: 127; Downloads: 6
Redirect to original
Description
I think it's over. I guess the picture looks nicer.
This time I can share model parts and extra texture files. Because there may be people who want to use it outside of XNA. There are some texture maps that XNA can not use. (Bump map It can also be displacement, subsurface map)
Bump map on alpha channel. You should do this manually.
I guess there is no texture for the tongue. For this reason you can only make it red or you can use face texture map.
In fact, this mount is not red anyway.So you can do as you like.
Please indicate if there are any problems.
I did not name the bones. You already know me. I'm lazy.
I did not use a MicroBump. Because normal maps is not bad at all.
The file is in *.ascii format. (Generic_item.mesh.ascii)
For XNA:: drive.google.com/open?id=1Pwup…
All files:: drive.google.com/open?id=1yscN…
Related content
Comments: 30
👍: 0 ⏩: 0
👍: 0 ⏩: 0
👍: 1 ⏩: 1
👍: 0 ⏩: 0
👍: 0 ⏩: 1
Sorry unfortunately. This is only created for XNALara XPS. A file in ascii format, You can easily transfer it to any medium.
I can't help with that now. But maybe it's something you look for. steamcommunity.com/sharedfiles…
👍: 1 ⏩: 0
Mr 47 is a badass character, thanks for sharing this one!
👍: 1 ⏩: 1
Thank you for this.. Already tested him out..
Now if the weapons are available..
Or the sniper briefcase.. It will be more amazing..
👍: 0 ⏩: 2
👍: 0 ⏩: 0
Maybe one day...
I will try for that day.
👍: 0 ⏩: 0
Interestingly, I did not know that XNA does not support some textures.
On the contrary ,in particular Bump maps ... , Displacement Maps and subsurface scattering Shader are very common in XNA.
👍: 0 ⏩: 1
I came back.
Okay... This is a really bad situation. But XNALara has already been updated on the latest july 2016. I guess there was no update after that. Xnalara is too late for new technologies.
I always wanted to have ambient occlusion plugin for xnalara one day. I think 3rd party is technology. (3rd Party Softwar) It's a hard dream to achieve.
👍: 0 ⏩: 1
On the one hand I understand your arguments, on the other hand I can not confirm them.
Correct is that the last publicly available version of
XNALara has been updated on June 2018
and that the last publicly available version of
XPS has been updated on July 2016.
On the other hand, my links are from 2008 and 2011. So these are not new technologies. The Bump map technique is the oldest one, developed by James F. Blinn, and described 1978 in Simulation of Wrinkled Surfaces
So nothing new.
It is newer too late for new technologies 
Last week I released such an extension here: New XPS Render Groups (and currently is a new extension under construction)
Not sure what you mean by "Ambient Occlusion Plugin".
- My New XPS Render Groups use the XPS shader plugin interface, included in XPS since version XPS 11.5 ( Feb 20, 2016)
- "Ambient Occlusion maps, we have since XNALara version 1.0
Not sure what you mean by "It's a hard dream to achieve."
- To extend XPS with "3rd Party Softwar", like my
New XPS Render Groups
XPS -- Convert Low Poly models to High Poly models
XPS NextGen goes to HD -- High Poly models in XPS
XPS Realistic Lighting Overhaul 1.0
...
It's a dream that's pretty easy to be true. It's just some basic scripting knowledge, and some 3D knowledge necessary.
BTW:
You seem to use the terms "XNA", "XNALara" and "XPS" as synonyms for the same thing. This leads to confusion, and confused me as well. These are 3 completely different software products.
EX: Your Hitman 2016 - Unknown Suit model can NOT be loaded in:
nor in
XNALara version 9.9
nor can it be loaded in
XNA (by Microsoft) ...
Can I ask you something?
I am currently creating a Valve SMD importer as XPS "build in" (XPS extension). Everything works very well. But I can not figure out where the information about the texture names of the materials could come from.
My questions:
1) How did you find out which texture maps, from the "Texture" folder of your "All files" upload, match (belong) to which material (mesh) ?
2) Can you give me a link on any SMD importer, which one can load a SMD model with textures?
Thanks in advance, and never stop your great work.
👍: 0 ⏩: 1
I know that Xnalara supports Ambient Occlusion maps. But I want it to be real-time.
Because there are some problems. Because some UV maps that have the same texture map overlap each other. (drive.google.com/open?id=1iWVZ… ) This causes problems in the end.
Or when we move models that are close to each other, the darkness is still in the same place.
I do not think I can help you for SMD. I'm not so knowledgeable about SMD. Sory
MDL
,
Noesis can open "*.mdl" files.
I think texture information on SMD is not available. I think you should make a direct MDL importer. Because I think that SMD is the file that contains 3D information in MDL.
Think like a model in .obj format. The "Texture" information of the .obj format files is the contents of the .mtl file.
So "smd = obj"
I think the actual information is in the mdl file. So you have to make an .MDL importer.
You can ask for help from this forum. forum.xentax.com/
Or you can ask Rich.
twitter.com/DickWhitehouse?ref… , www.richwhitehouse.com/index.p…
Hope it helps
👍: 0 ⏩: 1
SMD vs MDL
Yes it helps. I will ask "Mr Adult" (Rich) how to interprete the hash codes like 36836F461E7B31 to find the texture.
I know that for the OBJ format, the content of the .obj file is the geometry, the mtl contains the material (texture, ...) information and the .arl file contains the bones (armature).
smd and mdl are two different model formats by Valve. So it is not right that SMD is the file that contains 3D information in MDL.
If you compare smd with obj, then you would have compare mdl with mesh.ascii.
Your upload "All files:: drive.google.com/open?id=1yscN… " does not contain any .mdl files. Just textures, smd and .ascii (with number of textures eq zero)
Ambient Occlusion (AO)
Haha,, we all want "Real Time Ambient Occlusion". Unfortunately, this is not possible. No graphics card is able to calculate Ambient occlusion (Object Space AO) in realtime.
To bake a single AO map, today's hardware needs a dozen seconds. A model is build with multiple meshes. A scene contains a couple of models ...
No way.
2007, NVIDIA has published the Ambient Occlusion technique. To bake one single AO map, using a special Hardware-Accelerated Occlusion, the preprocess took approximately four minutes (240 sec) with a software ray tracer. To do it in real time (slow laggy 25 FPS) the process must be 6000 times faster! The idea was that the GPU speed will be 2 times faster every 2 years, so maybe 17 years later it would be possible (if not every 3 years the poly count would be twice and the screen resulution too) ...
No way.
Right, Ambient Occlusion (Object Space AO) maps does not depend on the pose, and AO does not depend on light direction. When we move models that are close to each other, the darkness is still in the same place. I am amazed that models with AO maps are still available today. Just like the predecessor of AO, vertex painting. Right both techniques are supported by "Xnalara"
Solution:
In order to achieve real-time framerates, several methods have been developed which approximate the effect in screen space. This days, the game engines use a "real-time approximation of Ambient Occlusion" like SSAO, HBAO or VXAO ...
The main idea behind these algorithms is this: for every pixel on the screen, sample a set of pixels around it from the depth buffer, and compare the depth values to get an estimate of the amount of occlusion of the pixel. So these algorithms compute the ambient occlusion in a full-screen pass, using the depth buffer (Z-buffer) as the only input. Like the AO maps, the sampling ignores usually the lighting information of the scene to produce the final image.
To simplify the explanation, if a section of the screen shows an object and some neighbor pixels show this or another object at a much closer distance to the camera (but not too much distance), then this part is drawn darker.
The result is a sort of black outlines, if a character is near a wall:
vs
In XNALara, non of this "real-time approximation of Ambient Occlusion" is implemented.
For XPS, there was a "Depth map" shader by XNAaraL (the XPS developer) available ( Shadow_Render_Pass, it was improved by my self). Together with a tutorial to create also a depth of field effect.
Unfortunately, the development of XPS was stopped because the developer was tired of being constantly insulted. EX:
- KyleNeaj-AneiKeno , insult the XNALara_XPS developers as son of a bitch and wanker
Better solution:
The sampling can be done in 3D as well, but it requires having the positions of the objects rendered at each pixel, which can be either directly retrieved from a buffer, or reconstructed from depth. In addition, surface normals can be used to avoid sampling below the surface and to attenuate the occlusion value depending on the angle between the normal at the point and the direction towards the occluder. A buffer with occlusion values is obtained from this algorithm, which is then combined with the lighting information of the scene to produce the final image. Typically the occlusion factor only affects ambient light, but you can also made it affect direct light to achieve different results.
One of this techniques is called "shadow mapping" and as "Advanced shadows" in XPS since version 11.7.
Not so easy to adjust (and it should be to improved as well). RadiantEld has written some tutorials
Oct 29, 2016 XPS Advanced Shadows
Jul 30, 2017 Shadow Tutorial, Part 1 Introduc tion
...
Mar 22, 2017 How I work with XPS and Photo shop
👍: 0 ⏩: 1
Yeah, The two are a different format.
but I'm talking about this. SMD only contains 3D geometry and bone information.
But the main event is the MDL format. If you want to make an export tool, I think you should do it for mdl.
In the Smd format, I think you can only learn the name of the texture-like material.
The tool I use is automatically exporting as SMD and ASCII.
(AO)
When I said that it should be "real-time", I mentioned the SSAO system. In a normal 3D model, the render duration is extended when AO is active. It's hard now for real AO to be real-time.
But I can handle it with AO Map. I am already correcting the mistakes in AO Map with Photoshop
insulting the developer is a really bad situation. 
I knew XNALara had "Advanced Shadows". But I did not know we could adjust this feature. This is really nice
👍: 0 ⏩: 1
Thanks again for your efforts. Very appreciated.
(MDL)
I do not want to make an export tool. My only interest lies in finding out how to create an import tool for XPS (and to understand something more about the smd format. which is so popular for some porters).
I have already completed the SMD import tool. I do not plan to program another import (or export) script. I think it's not necessary to do it for MDL or any other format. I know, some peoples ask to do it for fbx, psk, mdl or ... ; but there are already many tools to convert these formats to xps. Like Noesis by Rich Whitehouse together with the import plugins by chrrox and the mesh.ascii export plugin by XNAaraL
(SSAO )
I do not like any AO. I personally find AOs look really stupid, in most cases, because they ignore the light direction (and AO maps moreover ignore the pose).
To be honest, I tried to implement SAAO as a third party plugin for XPS.
- The original SSAO implementation by Crytek had a "depth buffer" as input. The XPS shader interface does not grant access to it. In XNA it is possible to use two or more passes for the algorithm, to store this "depth buffer" per-pixel position in a "render target"'; as input (texture) for the next "pass".
- XPS does not provide the render target of the previous pass as input for the next pass
Conclusion
- The SSAO method is very well suited for games using deferred lighting pipelines because it requires two buffers that are usually already available; but not provided by the XPS shader plugin
- AO alone looks boring. XPS does not mix the result of a custom shader with the existing effects (render groups). The ambient occlusion output must therefore be mixed in Photoshop with the normal render pass. Post-processing will be necessary.
- The SSAO has the same limitations as other screen-space ambient occlusion techniques: Disadvantages:
- Does not take into account hidden geometry (especially geometry outside the frustum).
- The performance is very dependent on sampling radius and distance to the camera, since objects near the front plane of the frustum will use bigger radiuses than those far away.
- The output is noisy. Speed wise, it is roughly equal to a 4x4 Gaussian blur for a 16 sample implementation, since it samples only 1 texture per sample and the AO function is really simple, but in practice it is a bit slower.
One last word of advice: You should not need SSAO at all; maybe "light maps" are enough for your purpose as they can provide better quality for static scenes.
👍: 0 ⏩: 1
You're welcome. You too taught me a few things. thx
Nice work. The idea about mdl is your choice. It does not matter to me.
___
no problem. Maybe another day, another time... But you are right, "light maps" already provides what I need. the links you show are really good.
👍: 0 ⏩: 0
ohh yeah. I also want to do that. I have FC5 among the things I want to do. But I am very busy these days.
I'll do it when I'm free time. in list
👍: 0 ⏩: 1
Awesome work! Thanks for including the bump and sss maps as well!
👍: 0 ⏩: 1
You're welcome. I hope Maps will fit what you want.
👍: 0 ⏩: 0
OMG, Thank you. I've been wanting a model of him from the 2016 Game for a while.
👍: 0 ⏩: 1