So it's been maybe four years since I've touched the HEK in any way. I think I'll try to get back into it by making...!! ! ! ..props. Am practicing texturing with blender

First item:

-----(Decoratives):
Decorative_Wallpanel.scenery
--- Has no collision, I don't think it'll need that. But I've set up the bounds just in case


Todo:

1:)Rip chainlink fence sounds from Dino Crisis 1 and make a Chainlink Fence Door. I already have the texture and a blank device machine model that can be fired through with bullets.

Chainlink Fence Texture to use


---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
Are there spoiler tags I can use to hide images in?

I don't have any of my old stuff to work off of xD
Unless someone here has tot_highpoly.map or errortest.map or d003.map(a build of jail-type map) they can give back to me if they (for whatever reason...) still have those maps somehow

EDIT: I have another question !
If I wanted to make an animated texture, am I FORCED to use the blue-borders//spritesheet trick that halo uses ? Or could I simply make a multipage tif the classic way and import that? I'm asking because I don't have the means to make a multipage tiff yet...
And which one is the animation sequence anyways? The vertical stack one? Or the Horizontal stack one?
Edited by OrangeJuice on Jan 6, 2017 at 01:36 AM

If you want your sprite to be animated arrange it horizontally. (smoke, fire, lightning)

If you want your sprite to be un-animated arrange it vertically. (multiple sprites arranged vertically will act as individual sequences)

Halo will only interpret an image as a sprite if the .tif you are compiling uses a true blue solid background/boundary. (R-0, G-0, B-255)

For images which are inherently luminous or shiny it's best to use solid black foregrounds. I'd put stuff like sparks or shiny beams of light within this category.

Stuff that is generally more how can I put this.....rigid? Such as rock, dirt, generic debris and what ever else that matches that description should use a transparent foreground.

Blood splatters and the like work fairly well with just a solid white foreground's minus the need for an alpha.

Compression type should reflect what you are trying to achieve. For example if you feel you are close to hitting the "tag limit" imposed by tool i'd recommend nothing higher than "interpolated alpha" if you can avoid it. But if you are just messing around "32" or "16" bit compression depth would be the best choice quality wise.

Pro tip: Frame blending is very important in getting your sprites to appear in the correct manner.

Alpha blend as a basic example should be used on those sprites which I mentioned that feature "luminous" content since this particular mode will treat black as fully transparent and white as fully opaque, thus rendering your .particle bitmap or whatever exclusively and without the sprite sheet's foreground.

Apologies if the explanations are a little hard to follow, I'll re-bump with images later.

Bitmaps are not stored in the tag data section of the mapfile. They're raw resources, and when internalized are located in a separate section of the .mapfile, or when not internalized are stored in the external bitmaps.map file.


What this means is that the size of the actual image data has no bearing on the tagsize limit that Halo has. While you will eventually hit an engine limit, it won't affect the size of tagdata in the mapfile. You could compile everything as 32-bit true color and, while bloating your mapfile, it should compile just the same.

^ That is true for SP, but for MP it all counts towards the tagsize limit.

No one at this point still uses the default tool for multiplayer maps unless they are using classic tags. So this does not apply.


Also, with bitmaps you can still hit memory limits, I know CE only detects max 1gb of allocatable ram, and making a mapfile over 700+mb (something you normally can't do) makes the game crash on load (even though I never hit the tag size limit). The game without opensauce will also not show any maps above ~380mb in size in the multiplayer map list.

I'm pretty sure some people still do, even if it isn't the best route to go down.





Back to sprites'n'stuffs.




Since the sprite creation process is more of a free for all and also since there is no generally accepted workflow I'm going to attribute my own terminology here.

Background = The solid blue background that every .tiff requires in order to be considered a sprite.

Midground = Is the solid black or white tile you would use to display your source footage upon. (Note midground's are redundant if you are using a foreground with alpha properties)

Foreground. = The actual bitmap it'self you wish to be rendered in game.

Here is an example of a "blank" sprite sheet which one would use for animated sequence:



Some thing to note here is that as a whole the image equates to 1027x258. The reason for this is because I wanted to incorporate 4 black midgrounds @ 256x256 for neatness sake. As a general rule a sprite sheet can have pretty much any dimensions, this includes the background & midground. (The foreground is irrelevant since it's dimensions will always be constrained to the midground unless you want clipping.)

Lastly unless specified otherwise in the .particle or .effect tag the sequence will always play from the start to the end. You can randomise the actual start point of your sprite within the .particle tag but it will only cutoff once it has run through all of the tiles. Again there are flag fields which you can manipulate to alter this (correct me if I am wrong) but that's straying away from the main topic.

And here is the polar opposite, an un-animated sprite sheet w/roughly the same dimensions:



The main and pretty much only difference here is that each tile is it's own individual sequence. To explain it further a vertical sprite would be best for "fast" and "poppin" fx. Or if you simply want to use a static bitmap and configure it with different variations such as the blurred rain drops used in the plasma pistol's charging effect.




Side notes:

Apparently since the colour code 0,0,255 is reserved exclusively to differentiate a standard bitmap from a sprite the pixels which make up the foreground of said sprite cannot share the same colour code. I haven't tested this in practice but it's what I was told so take it with a grain of salt.

You can't physically extract a sprite and expect it to look the same as it did on import, this in many ways sucks but I haven't yet come across a bitmap extractor that can perform this task flawlessly (if you have let me know!). Although it's not that much effort to re-create the sprite again based off of the extracted bitmap files.



If it's any help to anyone here are some other of my own (old) personal examples. All of the source footage was created by me from scratch, don't steal and claim as your own.

Some sort of animated smoke effect for an AR?




Random frames of fire which I used within this flame emitter.




Side ejection 3p muzzle flash from an early VKMT H4 BR which was forgotten or tossed away?


Edited by Super Flanker on Jan 7, 2017 at 05:41 AM

How has it been like 16 years and nobody put WD-40 in halo yet?

Since I haven't been home in a while and I'm without a tablet, I've just been screwing around in 3DSmax for fun. So I've been putting in a few hours practicing UVW Unwrapping:





I finally have an excuse to use a multipurpose map too, like the bottle cap. It's just solid, basic-red in the colormap. But those ridges in the plastic are 2-pixel wide vertical lines in the reflection-mapping of the multipurpose, so it's really low budget. I'm having lots of fun!

So now we have WD-40.


Also making stairs because of boredom too. I've been plotting the number of steps and required height on a TI89, and manually setting all of the step heights by just looking at the data. I ended up modeling an elbow stairs and a spiral stairs:



I've been experimenting with using all Render-Only collisionless materials too. So I can get as fancy as I want and not have to worry about halo freaking out about it. It worked out years ago for highpoly Hyrule and I'm glad I still knew how to do it nowadays too.




With that in mind, adding fake collision to an otherwise decorative piece of BSP or scenery is actually pretty easy since... .well.. I've been using goddam halo for 16 years.
With LargeBodyCollider Materials, you can even get fake geometry to recieve DECALS too. So hah.

TODO:

WD-40's plastic cap needs the groove for the straw, and it needs the little dimple from where the plastic is injected
Edited by OrangeJuice on Feb 24, 2020 at 01:46 PM

More canister !




EDIT: Ink was a little bit faded, so I guess it's time to match it



TODO:
()Model the dispenser tube.

(done)Multipurpose the plastic top, needs grip bumps like the WD40.

Edited by OrangeJuice on Feb 25, 2020 at 09:26 PM
Edited by OrangeJuice on Feb 25, 2020 at 09:27 PM

WD-40 is an Easter egg that had incredibly untapped potential