sparky has contributed to 1921 posts out of 466156 total posts
(.41%) in 3,187 days (.60 posts per day).
20 Most recent posts:
Portals are not important. The matter you should consider are clusters -- "cluster portals". Portal planes are simply used to define clusters, which is what the game engine uses to separate geometry, but not just for rendering, but actual recognized areas such as wind and sound. Basically, it's a way to show the game engine what resources it needs to use for environment processing. Units (bipeds and vehicles) and other Object-related tag types use Levels of Detail and are not culled, whereas audiovisual elements like ambience, sound, and wind related to the SBSP tag are managed. To demonstrate this, swap the bloodgulch terrain's .shader_environment tag reference in Eschaton for a transparent shader, so you can see through the terrain. Then watch the flag movement inside the base as you move near the base exits, to see what happens to the processing of wind as the base interior goes in and out of culled view. See, it's not a matter of what you see, but of where your player camera is in the game environment. It's basically a whole Direct3D / OpenGL issue with limitations imposed by the game engine (which can be altered through modifications like what OpenSauce or HAC2 do with "increased render limits"). It does not have to do with your +portal geometry, so it's not really a question of how to best make +portal volumes, but how to make a level that can be segmented into clusters without causing too much overlap in cluster references -- so that when you're looking in a certain direction, you don't look into other clusters at angles that would make it "difficult" for the game engine to determine whether or not your camera is actually looking "into" or "at" that cluster volume. So that means you should keep all your +portal geometry away from sharp angled areas, and when there are sharp angles, use +exactportal instead.
What you see -- the camera view -- is already culled by OpenGL or Direct3D or whatever the rendering engine is that's being used. Only what the camera views is what is rendered, and so that's why you can look at something directly and it will be fine, but by turning the camera to the side towards a 90-degree angle of view of that object, the object might start to disappear from view, or parts of its geometry might visibly vanish. The game engine needs to calculate the camera field of view and such to determine what should be rendered. And if you have complicated geometry or portal areas, that is made difficult. But the game engine loves +exactportal volumes, because they can be rendered at a specific viewing angle to the contained geometry.
So basically wherever you have some sharp angle in the SBSP, figure out a way to use +exactportal instead of +portal, and only use +portal for defining large cluster areas, to segment the geometry for engine limitation purposes (like avoiding too many triangles per cluster).
And the main reason why B30 had so many clusters was because the map designers apparently wanted to have different ambience based upon where the player was, so that being close to shore would produce a different ambience, and being in the interior would be a different sound, and being near the entrance to the "museum" would be a different sound. So it was mostly about "what is this environment supposed to be, in terms of wind and sound" rather than worrying about culled faces with geometry rendering.
Edited by sparky on Mar 18, 2018 at 09:15 PM
If your geometry clips like that, try making those buildings into scenery instead, and using LODs. There is a limit to the amount of scenery that is rendered at once when facing a certain direction, but the LODs should help. And they are large enough that damage passing through them shouldn't present a problem.
Edited by sparky on Mar 18, 2018 at 09:18 PM
And remember to set the .shader_model material properly, because no matter how fancy a map is, if all the material impact responses are dirt -- if when you shoot at every object, it emits dirt particles -- then the map is basically unplayable.
Edited by sparky on Mar 18, 2018 at 09:21 PM
Ask Fulsy#1228 on Discord.
Quote: --- Original message by: SBB_Michelle
a better URL for it
Try https://goo.gl/ or https://tinyurl.com.
Try my current web site and video tutorial series:
I didn't even know that Halo Demo / Halo Trial had an Xbox version. Wow.
Edited by sparky on Mar 17, 2018 at 09:05 PM
Try this sequence:
1) Make +exactportal volumes to seal off enclosed areas.
2) Look at your terrain geometry overhead in wireframe view and use +portal planes to divide sections of dense geometry, but such that the +portal plane faces do not intersect the +exactportal faces.
I have exclusive write access, as it is a web-accessible directory. These are all the files in the Halo Maps Archive, which includes more than maps. If you want to release a map for now, maybe try the CE3 web site. Other venues are being developed by myself and others for uploading maps.
Check .actor, .actor_variant, .biped, and .scenario's "encounters" block for dodge chance values.
Quote: --- Original message by: Bungie LLC
This must've been buried in galaxyverge's file hierarchy. This was one of the first domains I went to search for, but after scouring through the main page, I came up empty. Doesn't surprise me one bit though, considering Sparky's the webmaster.
This appears to be what I was looking for. Thanks a ton.
Back at ya!
The mirror at this location will be shutting down in a few months. If you want, use a tool like wget to quickly download all the files in that directory before that point. Bandwidth is not a concern.
Quote: --- Original message by: MosesofEgypt
The MEKE is only for 64bit Windows
I installed it on Mac using WINE. It works using wine64-preloader. I can even run Guerilla.exe and tool.exe on Mac using WINE, but Sapien has some problems.
I just completed my initial work on HEK tag file structs. Here are the relevant files. I used my retribution.h file and some other of my work to design nested structs for all the HEK tag file types. There is still much additional work to do, but I'd like to submit these files for peer review. If you don't have anything to say about the code itself, please at least let me know what you think of this work in general.
The next step is to go through and confirm max reflexive sizes. I consulted Moses of Egypt's work for this until now. (Thanks.)
Afterwards, I'll do parsing functions for all the structs. These I will use to verify the comprehensiveness of the structs. Note that the purposes of several undocumented metadata values must still be determined.
The main goal I have at the moment is to make a replacement for Sapien -- something as simple as a 3D view of the terrain and which can be used to modify .scenario tag data. I plan to use OpenGL for rendering.
--- EDIT ---
I corrected all the max chunk counts. I used Mozzarilla for testing large chunk counts.
MosesofEgypt: The only reflexives that have a maximum of 65535 chunks are:
- coll/sbsp: bsp2d nodes
- mod2/mode: uncompressed_vertices
- mod2/mode: compressed vertices
- mod2/mode: triangles
All the others that say 65535 should actually be 65536.
I'll update the link after I check all the reflexive signatures for duplicates and further optimize.
Edited by sparky on Mar 8, 2018 at 08:32 PM
--- EDIT ---
Updated download; optimized some more reflexive structs.
It's worth a repository at this point, since the structs are basically finished, so I'll go ahead and do that...
Edited by sparky on Mar 8, 2018 at 09:50 PM
--- EDIT ---
halo GitHub repository
Edited by sparky on Mar 8, 2018 at 10:27 PM
--- EDIT ---
I'm making a demo application to test retrieving static strings from a plist file, where I intend to store all the strings that show up in Guerilla's tag document windows. I'm copy/pasting the strings directly from what is essentially Guerilla.exe.
Before I post anything usable, I'm going to be away again for a while. I'll stop back at this forum to post useful things and otherwise experiment on my own.
Edited by sparky on Mar 9, 2018 at 01:33 PM
--- EDIT ---
demonstration Mac application and source code (Xcode) showing loading text from a plist file
Edited by sparky on Mar 9, 2018 at 06:54 PM
--- EDIT ---
plist in progress
Edited by sparky on Mar 12, 2018 at 09:35 PM
Yeah I didn't mean to broadcast any problems with your code, so no offense intended. Thank you for clarifying and for the clever suggested approach to identifying these software limits. I did use an auto-clicker at 5ms click interval to click so quickly that I could step away from the computer for a few minutes and it would already have done the hard work for me without any effort on my part. I needed the stretch and food break anyway!
And thanks for letting me consult your existing work for these things that I struggled with in the past. When I go back to check my work, I'll do a once-over on these things however it seems best at the time and then I'll have something to post online.
I was considering switching from GitHub to BitBucket. So another question:
2) Which open source software repository do you recommend?
It seems like if I wanted 3 free private repositories, BitBucket is better than GitHub. If I wanted only public repositories, GitHub is better than BitBucket.
Edited by sparky on Mar 6, 2018 at 05:53 PM
Just some last-minute questions I'm throwing out there as I go along in my daily programming. I'll edit or reply with more questions for anyone interested to answer.
Let us begin.
1) I'm wondering why SBSP leaf map leaves are max of 256 when the guerilla interface allows for more: https://bitbucket.org/Moses_of_Egypt/reclaimer/src/81deb9bf5bb07a24981fdb8f1150fc7735e26bc4/hek/defs/sbsp.py?at=default&fileviewer=file-view-default#sbsp.py-435 . How many max leaf map leaves is it really?
Why? My structs are crying. I will use a super duper auto-clicker to test... Wine interface updates every 5 ms it seems... and the verdict is that Guerilla allows for 65536 chunks. Any reason to limit to 256?
Edited by sparky on Mar 5, 2018 at 08:15 PM
I'm leaving the community. I wish you well.
Your .sound tag needs mouth data. Mouth data is a sequence of bytes where 0x00 indicates complete silence and a fully closed jaw and 0xFF indicates maximum amplitude and a fully open jaw. The sampling is 30 bytes per second of audio, to correspond with the animation rate of 30 frames per second. Alter the sound tag to add mouth data by setting its usage to dialogue and running the audio file through tool again.
You should wait until it's done. Then you can rename everything as a project contributor or with your own project or fork of it.
It won't matter to anyone but me, and I don't care that much since almost all the variables are already named by me. To the person who uses the function(s) for handling data, verbosity in variable names is helpful to identifying what is stored. I prefix everything since everything is loaded globally instead of contained within classes and objects.
Edited by sparky on Nov 4, 2017 at 01:48 PM
If you want to discuss your options in chat, contact me on Discord.
Edited by sparky on Nov 4, 2017 at 01:43 PM
I'm making a C library that parses Halo files.
I'm working on the tag file formats first, then map files, then probably back to other kinds of data. The approach I am using is similar to NSData in Objective-C. I use fopen() to open a file, copy its bytes into memory and make a note of the file data length, close the file, copy the memorized bytes into parsing structs, and free the memorized bytes.
Eventually, this will facilitate designing any C-based application to read and write Halo file data.
Edited by sparky on Nov 3, 2017 at 01:09 AM