[App] Eschaton 0.7.2 - Beta

Utilities designed primarily for Halo PC.
User avatar
hiheyhello





Posts: 781
Joined: Sun Oct 07, 2007 11:03 am
Location: ontario

Post by hiheyhello »

still trying to get used to it :? great app alt.
Tural wrote:I like to pretend I have friends.
User avatar
Altimit01




Connoisseur Snitch! Literarian 500

Posts: 947
Joined: Sun Jun 04, 2006 12:10 pm

Post by Altimit01 »

The problems with DDS files are unusual but probably come from not being extensively tested (as their is no native support for the format outside of windows).

That bit with the greying out is very unusual and shouldn't happen. The 64x64 shouldn't take any longer because I think I used mostly the same code as HMT does to do an inject. As for the massive bitmap image. What format did it happen to be in? DXT? I'd be quite interested in having some problem files to look at and try and figure out what's going on.
Image
Download Eschaton: Halomods | Filefront | Mediafire
User avatar
Suiadan





Posts: 20
Joined: Tue Dec 09, 2008 1:27 am

Post by Suiadan »

I believe that it was *checks* DXT 2/3 and my bad, the one I had trouble with was the 2048x2048...here, I'll PM you with a map that has it internalized....the image is effects\particles\solid\bitmaps\snow flakes
User avatar
bcnipod





Posts: 3580
Joined: Tue May 15, 2007 8:52 am
Location: 45 Minutes outside Boston
Contact:

Post by bcnipod »

I did not know halo supported bitmaps that large natively. And yes, until there is a dds plugin for mac photoshop, i and none of the mac testers can really try out the dds injection system.
Twitter: Dirk Gently | Major lulz
Mr. Brightside: Worst mod I've seen since 'Nam.
Website
User avatar
Altimit01




Connoisseur Snitch! Literarian 500

Posts: 947
Joined: Sun Jun 04, 2006 12:10 pm

Post by Altimit01 »

Well I found part of the problem at least. The way the program handles image loading is that it not only grabs the image itself, but all the mip maps as well. I've fixed a problem where for every mip it reloads the entire image. Now it will hold on to all of the data without reloading. This won't make it any faster at loading because we're talking about processing 5,505,024 pixels stored in 16 pixel blocks which in 2/3 compression is about 128 bits per block. And because it's a compressed format there are some unpacking operations necessary. The benefits of not loading the mips is negligible since each mip is a quarter the size of the original. It's just that the image you're working with is massive.

I'll be looking into the DDS inject problem presently.
Edit: looked at the particular DDS you sent me and to be honest I think it's the DDS at fault. I looked through the header information and it included nothing regarding mip map levels which the bitmap has. Additionally it didn't use the FOURCC encoding to specify it has a DXT3 image. The error message about the file being too large is correct. Bitmap data is stored exactly how DDS files store them without header information and your DDS file was larger than the space that existed in the map.
Image
Download Eschaton: Halomods | Filefront | Mediafire
User avatar
Suiadan





Posts: 20
Joined: Tue Dec 09, 2008 1:27 am

Post by Suiadan »

I recently decided to see if Eschaton would actually open it and started it, checked it one and a half hours later, nothing left it again for over three hours, then I came back, and it actually was open! Took a ridiculous amount of time though...There should be a way you you to use the graphics card of the computer to do the heavy image crunch work...

For one, that paticular bitmap doesn't have any mip maps anyway :P
Then why did HMT inject it using the EOF trick just fine? Why did Eschaton internalize it just fine? Why did halo work just fine? Another pet peeve: HMT opens the bitmap in under 20 seconds...Eschaton much longer...

On a different note, Here is an idea that would probably take some doing; a recursive reflexive cloner. Basically, allow you to dup any reflexives at any level. One use of this would be to use the model plugin that allows editing of markers. With something like that you would be able to dup those markers, triggers, anything that used reflexives! For example, that would theoretically allow you to add seats to vehicles for example...the theoretical possibilities are almost endless! Dup the trigger of a flamethrower, making it dual triggered and you could make the second blue for example.
User avatar
Altimit01




Connoisseur Snitch! Literarian 500

Posts: 947
Joined: Sun Jun 04, 2006 12:10 pm

Post by Altimit01 »

With regards to that image I looked into the actual bitmap tag and it did indeed have mipmaps. The original image and two mip levels. Your DDS file had none. Additionally the DDS file had significantly more data than the version which was already in the map. The reason the EOF trick worked was because HMT allows it to write the entire data section to the end of the file and then created new bitm tag data based off of the DDS header information which then overwrote that section of the original bitm tag. The reason Eschaton did not allow the injection was because the DDS file was not the same size and did not have the same data encoding as the original file did. There EOF allegory "inject as new" is designed to allow for the main use of the EOF trick by modders to allow for bitmap editing that does not alter bitmaps universally.

DDS is a very straightforward container format, and S3TC is a fixed ratio compression system. For X many pixels compressed using Y format you will always get Z bytes. Compression format used, mip levels, mip depth, and other options are all specified in the DDS header. The fact that the data size was larger (meaning it was not compressed in the same format) and did not specify in the header the same options as the original clearly indicates that the DDS file was the problem.

Short of rewriting the method by which the program itself is able to display images and having it integrate with a graphics API there is no way to offload processing to a GPU. I really wish I could but without a lot of low-level coding it's not feasible. (Just wait until I "fix" the bitmap importing process with an option to use nVidia's multi-threaded brute force cluster fit algo rather than the current range fit algo for better quality compression. Again it'd be on the CPU instead of the GPU.)

As I've stated many times in many places with regards to image loading, the slowdown comes from the specifics of how the environment handles images. Since VS is so heavily tied into MS, it can leverage direct bitmap support. That is not the case with any other high-level programming environment. I really wish it were possible to have an easily accessible method for that kind of manipulation.

I've been long considering the method which allows for chunk duplication. It's a feature that has been in mind since 0.7 was designed and is quite possible using the capabilities of open and expand. It just has to be implemented and integrated with the UI. That last part is probably going to take the longest.
Image
Download Eschaton: Halomods | Filefront | Mediafire
User avatar
Suiadan





Posts: 20
Joined: Tue Dec 09, 2008 1:27 am

Post by Suiadan »

I understand what you mean on the slowdown issues, can't be easily helped...

Huh, I never noticed the mip maps...odd...I assume that the reason that Eschaton wouldn't inject new copies of the same bitmap after I used the EOF trick with HMT was because the headers were out of whack? annoying...Meh, whatever :)

Also, the reason that I find the EOF trick so useful is for that very reason, maybe you could add a option to it that way as well? perhaps a option in the Prefs to do it like that?

I certainly look forward to the cloning feature :)

Though I have been wondering, couldn't you also theoretically do all this stuff on a non-expanded map?
User avatar
Altimit01




Connoisseur Snitch! Literarian 500

Posts: 947
Joined: Sun Jun 04, 2006 12:10 pm

Post by Altimit01 »

Theoretically yes. However any chunk cloning would increase the size of a meta file. Which would mean shifting all of the tags after it further back. It would also mean changing the offset values. The difficulty associated with doing this on a compiled map compared to an expanded map where each meta is a discrete piece of data that is later compiled during the rebuild process. The chunk cloner only works on scnr tags because there is extra empty space which can be used without needing to shift data.
Image
Download Eschaton: Halomods | Filefront | Mediafire
User avatar
Suiadan





Posts: 20
Joined: Tue Dec 09, 2008 1:27 am

Post by Suiadan »

Meh, true enough...Course, (correct me if I am wrong) even with the [scnr] has limits on how many free spaces, I have run into that many times with scenery...Would it be possible to add more empty slots for scenery, itmc's, and all the rest? if so, that would allow for much more complex scenery-based maps...

Also, I have been thinking about DH's collision editing tut's, I was wondering, wouldn't it be possible to make a model with just a cloud of points? I believe that DH's plugin makes it possible to edit each vertex, so couldn't you import and export them in some kind of model format? that would theoretically make it much easier to edit collision models...
User avatar
Altimit01




Connoisseur Snitch! Literarian 500

Posts: 947
Joined: Sun Jun 04, 2006 12:10 pm

Post by Altimit01 »

The big problem with collision models is that there's more to it than simple verts. In fact it doesn't even use the traditional verts and inds method but instead uses a vert and edge method combined with plane vectors. Look into the discussion topic on DH's coll model plugin development.

Adding truly empty slots when there are none would mean having full documentation on the default and acceptable values for a given reflexive. There would be no limit for chunk cloning since it would not be using the empty space at all but instead increasing the size.
Image
Download Eschaton: Halomods | Filefront | Mediafire
User avatar
Suiadan





Posts: 20
Joined: Tue Dec 09, 2008 1:27 am

Post by Suiadan »

Yes, I know that, however, for simple stretching DH came up with a plugin to change the position of the verticies, wouldn't it be possible to make a program to export each of those as simple point cloud of verticies? then any model editor can change those by just selecting and moving the verticies around. Then the same program could import those back into their original places, thus stretching the collision model. Yes, this would be imperfect, but it would be much easier than changing each one manually in Hex or using that plugin...
User avatar
Altimit01




Connoisseur Snitch! Literarian 500

Posts: 947
Joined: Sun Jun 04, 2006 12:10 pm

Post by Altimit01 »

In my experience most modeling programs don't handle individual points very well. Most of them require at the very least some sort of face or similar value. I'll look more into the obj format and see if there's anything worth using though.
Image
Download Eschaton: Halomods | Filefront | Mediafire
User avatar
Suiadan





Posts: 20
Joined: Tue Dec 09, 2008 1:27 am

Post by Suiadan »

Meh, I guess, still would be handy though :)
stormblitz96





Posts: 5
Joined: Mon Mar 09, 2009 11:31 am
Location: Ahem...
Contact:

Re: [App] Eschaton 0.7.2 - Beta

Post by stormblitz96 »

Very nice job!
This is about 10 times better and more complex then HMT :shock: !
Good modifications must take time...
Post Reply