FiftyTifty

Members
  • Content Count

    16
  • Joined

  • Last visited

Community Reputation

0 Neutral

About FiftyTifty

  • Rank
    Member

Personal Information

  • Specialty
    None

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Still working on this, in-between the other stuff I'm doing and researching. Made more progress. Since the string block for LightIntBand.dbc is literally a single byte with a value of 0x00, adding and removing records is painless to code. So that's a new feature; you can add and remove entries. And since Delphi uses pointers to fill that tree panel on the left, it's also easy to make another TMemoryStream, read all the records that are still present in the tree as well as those that have been added, chuck them into an array, punt the header and string block in, and bam. New LightIntBand.dbc file that requires no other programs to work with, and it's just much easier. Any feature requests? I'm not a proper programmer, so I won't be able to do fancy stuff.
  2. Batching's different; that's when the 3D data of multiple models is combined at runtime. Instancing is where the same object is drawn once, and then the GPU just redraws that same object wherever there are other objects with the same 3D data, rather than issuing another draw call. I'm certain that the grass uses instancing, as increasing the density barely adds to the draw call count. If there's no way to trigger instancing, are there other ways to reduce the number of draw calls for a large number of actors with the same model and texture? I imagine that creating proper WMO's with texture atlases is a way of reducing the total draw call count, but man, it would be great for Ice Crown to have decent framerates with the draw distance maxed.
  3. After digging through the renderer, I found that there are areas that issue a huge number of draw calls when the server's distance is maxed. Icecrown in particular is a bad offender, with there being over 8,000 draw calls issued at certain vantage points. Now, the grass uses instancing, so I'm wondering; is it possible to have other .m2 models use instancing? In Icecrown, it's filled with a hundreds of the same skeleton mob wandering around, a prime candidate for instancing. How would I go about making them instanced?
  4. Wait, it's just one byte in size? If that's the case, I can just add a wee button that allows the modder to append a new record.
  5. For a renderer mod that's being developed, I need a way to tell which zone the player is in, and the only real way of doing that is to detect for a specific mesh being rendered on the screen. I've looked at other addons, and came up with the following: local frame = CreateFrame("Frame", nil, UIParent) frame:SetPoint("Center", 128, 0) frame:SetWidth(256) frame:SetHeight(256) frame:SetAlpha(1) local model = CreateFrame("PlayerModel", nil, frame) model:SetAllPoints(frame) function ModelBasics_UpdateModel() model:SetModel("Interface\Buttons\talktome.m2") model:SetRotation(math.rad(0)) model:SetAlpha(1) model:SetCustomCamera(1) model:SetCameraDistance(1) local x, y, z = model:GetCameraPosition() model:SetCameraPosition(x, y, 0) model:SetPosition(0, 0, 0) end ModelBasics_UpdateModel() Which displays the following model: For some reason, I can't change it's position by editing "model:SetPosition(0, 0, 0)". It just stays in that exact same place. Is there anything I can do to change the object being rendered, and to rotate, and move it?
  6. As an update, here's what I've got so far: The only thing I need to know now, is how to handle the string block. Is it just 1 character for each record in LightIntBand.dbc?
  7. Aye that clears it up, thanks. So how it works, is that the header is 20 bytes in size, and the following records are 136 bytes in size. I took a look at using C# for this, but it's really not made for writing to hex, especially with arrays not having a fixed size option. Decided to use Pascal, and going to use Deplhi to give the IDE a try as it looks better than Lazarus.
  8. I've funded someone to look into WotLK's renderer, and one thing he found, was that while most lights in the game illuminate nearby objects by changing their normals in a really shit way, the NPCs near ".tele Duskwood", by the camp, have torches that use a better shader for lighting objects. They have a torch equipped, with it's item ID being 2081. I've found the item, but I can't figure out how lights are attached to equippable items. The Item.dbc file contains the item's ID, which also points to ItemDisplayInfo.dbc, that .dbc file having little in the way of intuitive documentation. It deals with geosets, which I assume have no bearing on lights, as it deals with toggling meshes depending on their ID's in a .m2 file. So how do I find the lights used by items, like torches and lanterns?
  9. Aye I would, the problem is that it's not written in a way that can be understood by people who don't already know how it works. That code example isn't even code, it's psuedocode that shows how the header is arranged. And that Struct{} part throws me off. If I understand it correctly: dbc_header Is a record that is at the start of every DBC file, and is 20 bytes in size (according to WDBXE, it's 32 bytes in size: (https://github.com/WowDevTools/WDBXEditor/blob/master/WDBXEditor/Reader/DBHeader.cs ). Then after the header, the actual amount of data for LightIntBand is (record_count * 134) bytes in size. So to get to the start of the data, we just move forward from the beginning of the file by 20 bytes (or 32, if WDBXE is correct). To get to the end, we then move forward by (record_count * 134) bytes. But then at the end of the file, is an array of characters, but is named string_block ? This is not intuitive, I've no understanding of the data that follows. Ooh, good find. I looked at the tool, and it's not exactly pristine in the way it's organized. There's also no documentation, so it's really not clear how everything is being handled. That's compounded by all the nested functions. What I'll do, once I can figure out how the LightIntBand.dbc file is arranged (already know how to parse the records, but not the header and character array), I'll just make a tool dedicated for editing that file. And since I'll be making more tools as I continue to explore TrinityCore, I'll use that knowledge and release more tools that are designed around the specific .dbc files.
  10. While there is MyDBCEditor, it's very unwieldy for the more exotic .DBC files, with it being rather useless for editing LightIntBand.dbc due to it treating four byte integers as a single dword integer, with no way to change that. So what I want to do, is create a tool that is designed for editing LightIntBand.dbc. Problem is, the documentation on the DBC files is rather jumbled, and there's no solid examples to work from. As in, take the header: https://wowdev.wiki/DBC There is no documentation on how to read, parse, and get to the data. It seems like the header even encases the actual game data, from what I could tell, with no mention of how to work with it. On the other hand, the documentation for https://wowdev.wiki/DB/LightIntBand Is pretty clear. The data is of a fixed size: There is one dword containing the ID, another dword containing the number of entries in the two following arrays, one array containing dword integers (16 entries * 4 bytes = 64 bytes), and another array containing 16 * 4 byte matrices (1 byte for blue value, 1 byte for green value, 1 byte for red value, 1 byte for whatever X is). That means every single record in the .dbc file is 136 bytes long, so once the header is taken care of, the rest is already laid out. So how do I read the header, in order to get access to the records inside the .dbc file?
  11. Thanks for giving me the step-by-step. It turns out that Northrend's LightID's are organized differently, with the default ones used in zones having a minimal radius, whereas in vanilla the default ones are applied to the whole map, and are located in the corner of the map data. Trouble is, I can't tell which map pins in LightMapper apply the zone-wide LightIDs. Any idea how I can find them?
  12. A big problem with the vanilla zones is that the skies are extremely low resolution, with the clouds being generated at run-time. WotLK has higher resolution skyboxes, not great ones mind, but better than vanillas. Unfortunately, the original ones were not remade, and look like they're made up of 64x64 textures. I've found the Lightmapper that shows the skybox ID's, but the WotLK nodes are extremely small, with most of the map not being covered by any pins. So how do I, say, find the skybox ID for the majority Grizzly Hills? Or even better, is it possible to have an actual texture rendered on the skybox, so I can create proper high detail skies?
  13. That's fortunate, just wanted to be sure. Seeing how they're all split by default into groups based on their texture, I'm thinking that I should just use a texture atlas, and make the WMO as just one big mesh to keep the draw calls way down. But how would that work with the culling system? I imagine that it's done per object group, so I would have to make each building's interior their own object group, but still have the exterior as one big mesh. But then again, I don't know how the culling functions.
  14. Aha! There we go. So a .WMO is essentially a collection of .M2 meshes, which you use to create the bulk of the scene. Is it possible to make the .WMO itself just one big mesh in 3DS Max? Or does it only take .M2 meshes as it's data?
  15. I'm looking to get started with modelling for WoW 3.3.5a, and I haven't been able to find much coherent information about the limitations and usage of .M2 and .WMO. From what I can tell, .M2 files are individual objects that are small in size. .WMO Files are a combination of .M2 files. But when should a .WMO be used, over a .M2? Is there an object bounds limit for .M2 files that .WMO doesn't have? For example, if I wanted to replace the entirety of Stormwind, is there a reason why I shouldn't just make a single large .M2 in 3DS Max, and instead split the model into sections as .M2 files, plonk them into a .WMO, and then place the .WMO into an .ADT? If I can use a single .M2 for a city, that would be ideal, as I would then be able to save on a huge number of draw calls by just making the architecture one big model.