13-11-14, 18:55 | #1011 |
Member
Joined: Jun 2013
Posts: 40
|
How can I compile model viewer?
|
13-11-14, 19:34 | #1012 | |
Member
Joined: Dec 2010
Posts: 2,773
|
On MAIN_SDL.cpp there is
#define SKELETAL_TEST 0 I'm guessing you simply change that. Perhaps a new release configuration would do the trick as well. I've not tried that because when I set #define SKELETAL_TEST 1 it doesn't look like the levels load or anything so I guess i'm doing it wrong. Quote:
That's right! Dreamcast format is so close. PS1 TR4/5 formats have quite a lot of changes due to it needing to be in its most optimal form. TR1/2/3 PS1 files wouldn't be too hard to get loading. Most complex parts would be texture/audio. PS1 format is pretty known now so I could consider it but it might be a waste. I'm not sure what's causing those bad polygons will definitely investigate it! Did you make any progress with Lara's hair? Last edited by Gh0stBlade; 13-11-14 at 19:48. |
|
15-11-14, 00:53 | #1013 |
Member
Joined: Aug 2010
Posts: 1,810
|
As I promised, I have updated the source code and scripts to support global pushable flag setting; that is, you don't have to scan through all levels and manually write down pushable IDs. Nevertheless, you can set entity flag afterwards to block out certain pushable; however, I doubt it will be useful until OpenTomb evolves enough for custom level building.
For now, all you have to do is update source code and replace your scripts - and then, all pushables in all game versions should work! Well, I got basic principle of matrix transformation multiply from TeslaRus; it's simple in theory - you just multiply own rigid body's transformation matrix upon Lara's head transformation matrix, and you get the position for the root mesh of the hair. But it's not the thing that is actually stopping me from progress. What's more important is that in TR4-5, Core changed the way hair behaves - while in TR2-3 it looked more like a chain of rigid bodies (without rotational limits, so that's why hair meshes could go wild all by themselves), in TR4-5 they used a method which is more similar to modern age soft body dynamics. If you look closely, you will see that Lara's hair can stretch, "compress" and fall from the shoulder very "fluidly", and it's a sign that engine doesn't use constrained chain of meshes as a basis anymore; they used something more complicated. |
15-11-14, 01:07 | #1014 | |
Member
Joined: Jul 2012
Posts: 4,286
|
Quote:
[R]........|S| [R]........|R| [R]........|S| [R]........|R| [R]........|S| [R]........|R| R= Rigid, S= Stretch Last edited by Boobandie; 15-11-14 at 01:10. |
|
16-11-14, 19:37 | #1015 |
Member
Joined: Dec 2010
Posts: 2,773
|
I guess i'm done with the TR5 Dreamcast level loading into OpenTomb tests. I *fixed* (if that's what it should be called) a small bug I created causing some meshes to render with invisible polys or not at all as Lwmte pointed out
The latest fix has allowed me to successfully load TOM.TRC a small test level used for AI with that mini watercraft thingy. Unfortunately JOBY1.TRC has an alteration to the way the textures are stored. I managed to figure this out and can load the whole level file but OpenTomb just freezes and I don't know the cause at the moment. Chances are it's just a slightly unfinished variant of the title screen level anyway. Still no sound effects support... I don't think it's worth the hassle implementing those. They're Yamaha ADPCM encoded which is different to the standard Microsoft ADPCM. It would require a complete decode then re-encode to Microsoft's ADPCM since that's what OpenTomb's audio system currently supports. Ffmpeg can convert the Dreamcast sound effects thanks to someone who figured this on another forum I had posted a sample on. If anyone wants to try out the test/final Dreamcast levels from their Dreamcast files they can simply compile this separate test branch for Dreamcast only. It is *hacked* to just load TR5 Dreamcast files since there's no file magic to do any checks. For the test levels you'll have to set DREAMCAST_BETA 1 because the sound map is smaller than that of the final game files. TR5_Dreamcast_Test Branch link Not much use for OpenTomb itself, but useful for those who might be interested in what exactly changed between the Dreamcast/PC files. Should be VERY easy to make most existing tools support editing/viewing Dreamcast files with this knowledge. ----------------------- Video: Skip to 4:25 for TOM.TRC! ------------------------ Regards. |
16-11-14, 19:50 | #1016 |
Member
Joined: May 2010
Posts: 1,187
|
^ You set the video as private, so it can't be watched unless a registered user is allowed by the video uploader. Set it as unlisted instead.
|
17-11-14, 15:39 | #1017 |
Member
Joined: Aug 2010
Posts: 1,810
|
Well, it's more up to SDL2, which could support Yamaha ADPCM, but currently is not (however, it's a big plus that they at least support MS-ADPCM, which saved us a lot of time with sound engine)...
I think you should save a loader somewhere (I'll download your branch and put it into my archive of TR-related stuff, so it won't get lost), because who knows how OpenTomb will evolve in the future... Maybe we'll be able to switch level file formats or loaders, which will allow us to load levels for various platforms at the same time. Now for the latest news! Currently TeslaRus is rewriting render section which is responsible for correct alpha blending with multiple layers of polygons with different blending operations. That is, if you have lots of objects (or rooms) with alpha blending in scene, they will be correctly sorted by their depth related to the camera. The technique is known as BSP tree, and is very common in contemporary 3D engines (it was actually there since Quake, but Carmack and his engines were always ahead of time ). Original engine never does that, which is most obvious when you try to combine different emitters or statics with different blending modes applied - things just get wrong with different translucent objects placed in different parts of the screen - I stumbled onto this while developing blending modes patch for TR4 engine. Most common example is Lara's shadow, which seems like it's always "sits" above any other translucent faces on the screen. So, I request someone (meta2tr, maybe? ) to create a test level with differently placed translucent statics and rooms featuring different blending modes to test out this new OpenTomb feature! I will try to create one for myself, but I'm completely not familiar with meta2tr software... And applying blending modes to TexInfos via TrTextur is a big pain! Last edited by Lwmte; 17-11-14 at 15:40. |
18-11-14, 14:18 | #1018 | |
Member
Joined: Nov 2005
Posts: 3,252
|
Quote:
Psst-- while you're at fixing and coding the transparency: add in the soft particles support! http://www.gamerendering.com/2009/09/16/soft-particles/ |
|
20-11-14, 00:50 | #1019 |
Member
Joined: Aug 2010
Posts: 1,810
|
So, here is the first BSP transparency test! Currently it's still buggy, as transparency doesn't work properly for movables, and it seems that double-sided transparency is wrongly assigned to all textures, and framerate significantly drops with lots of transparent objects in scene - but still...
Look how dark and light plants blend into each other - it is not possible in original TR engines, as it doesn't sort polygons by their position - hence, you will get misplaced polygons from one side or another. In OpenTomb, it looks proper from all sides. TeslaRus continues to optimize the feature, so the final one should be more reliable than now! |
20-11-14, 02:44 | #1020 |
Member
Joined: Jun 2007
Posts: 26,911
|
Wow, that's so pretty. Great job !
|
Thread Tools | |
|
|