FiftyTifty
-
Content Count
28 -
Joined
-
Last visited
Everything posted by FiftyTifty
-
Heightmap resolution <-> in-game map size?
FiftyTifty replied to FiftyTifty 's topic in Level Design
Ooh, I forgot about this post. I've been doing research myself using Noggit Red. The zones really do vary a lot, with the Orgrimmar zone being 3x6, and the border zone with Mount Hyjall being 6x6. The good news, is that tiled builds take care of any outright hardware limit (the RAM usage for 64k data maps...). Bad news, is that functionality is currently broken in Gaea. Another strange thing is the verticality in WoW's maps. Outlands has everything extremely high up, with the actual playable zone being extremely squashed. Vanilla isn't quite as bad, but the height is used just for a zone's base elevation, rather than having varied and interesting terrain. I wonder what the reason was for this? The software just wasn't great, and Blizzard kept with the same visual look throughout their expansions for consistency? Took a wee look at alpha maps, and it looks to be just splat maps rendered as three separate greyscale channels. But making them at 4x resolution for the best result...Ooft. Definitely need tiled builds to get fixed. -
I've experience with making heightmaps, and fancy having a shot at loading them into WoW. While I'm still in the design stage, I need a reference for how big the details and the overall geography should be. How big is a 512x512 heightmap in the game? Is that the size of a vanilla zone? Smaller, bigger? How large would a vanilla zone roughly be? Thanks in advance
-
I was reading through the texture docs over on Wowdev (https://wowdev.wiki/BLP), and found an interesting feature; some of the .blp textures used by WoW are in fact palette textures. But there was no elaboration or detail, so I've a couple questions. 1. By palette texture, is that the version where the texture is referencing colours from a master list of colours? Like old games such as Fallout 1, and Ultima Online; the texture references colours by an indexed palette? 2. If so, how do we make use of these? Create our own palettes, and our own textures that reference a palette?
-
There are several different formats for .blp textures. Several are just bog standard DDS DXTC formats, but one of them is to use an indexed colour palette of 256 colours. This vastly reduces texture size, at the cost of a limited number of colours in the texture itself. My question is, how do we make those indexed .blp textures?
-
Anyone know what the biggest texture size is for 3.3.5a? I know it has shaders for SM 3.0, so it has a mimimum of 8192x8192, but I'd like to make as few texture atlases as possible, so if it does support a max of 16384x16384, that would be great to know.
-
Yeah vertex only animation is usable for very few things, always better to use bones. Making an important tool behind a paywall is terrible, not going to support that. Guess I'll be waiting for Blender Studio, where I'll prep the model in 3DS Max then punt it into Blender. Has there been any ETA on Blender Studio?
-
There are plenty of tutorials on exporting and importing models as .m2 files, but I can't find anything on making new animations. Are there any guides available on how to work with them?
-
Grouping all data rows by Light Params? Mind clarifying what that means? I should have added text labels, but if you hover the mouse over the text boxes, hints will show up that tell you what the parameters do. As for adding and deleting data strings, do you mean more LightIntBand records? You can do that already by selecting an entry in the tree view, and using the delete/instert keys.
-
I've spent the past few weeks working on a tool that makes editing LightIntBand.dbc so much easier. You can get it here, along with instructions: And you can get the source here: https://github.com/MajinCry/WotLK---LightIntBand-Editor
- 2 replies
-
- 1
-
-
- dbc
- lightintband
- (and 2 more)
-
Version 1.01
233 downloads
There are generic .dbc editors available, but they are absolutely not geared towards being good for editing specific .dbc files, the first one I came across being LightIntBand.dbc. So I decided to make a program that is much easier to use, intuitive, and gives you an idea of what your changes will look like. Made with Delphi community edition. Should work on XP, will definitely work on Windows 7, 8, 8.1, and 10. Github repository: https://github.com/MajinCry/WotLK---LightIntBand-Editor It's very simple to use. Here are the steps: 1. Much of the interface is disabled when first run. To enable it, click on File -> Load... -> Select LightIntBand.dbc 2. Now the interface will appear, after freezing for a couple seconds. That's normal, the tree list of all the records just takes a short while to be populated due to all the records present. 2a. If you want to add new records, make sure the tree list is selected, and press the insert key. 2b. If you want to remove records, make sure a node is selected, and press the delete key. 3. Select a record from the list. There is a text box above it where you can enter an ID to go straight to that record. 4. The two text boxes above the 16 GUI entries on the right show the ID of the currently selected record, and the number of entries that will be processed by the client. 5. To change the number of entries that will be processed, click on the text box to the right with the drop-down arrow, and pick a number from the list. 6. To keep your changes, click on the Apply button. Note: This does not save the changes to the file. 7. To save the changes to a file, click on File -> Save... -> Save as LightIntBand.dbc -- There shouldn't be any bugs, as I've tested extensively. If any appear, please report them with as much detail as possible. -
Speaking of particles, I noticed that there are significant slowdowns in scenes where there's many of them being rendered, which I assume is due to the increase in draw calls. Optimization would be a great topic to deliberate on; does the engine use instancing at all for particles, and if so, how do we ensure that it's active? If there's no instancing, is there a way to fake particles, such as by having the particle texture have an alpha map on a gradient, with the animation just being a bunch of skinned polygons at different positions being moved by a bone? For making .m2s, one thing I've noticed is that the assets are very unoptimized for draw calls, as there's little in the way of texture altases. Now, with the sheer number of texture variations, it is unfeasible with Direct3D 9 to have large textures, as VRAM is mirrored into RAM. One solution, would be to make use of vertex colours, with the texture being completely greyscale. Is that possible with WoW's engine? If so, that would be a good topic to cover; using vertex colours to create coloured variations without having to create an individual diffuse map for each variation.
-
Aye, having something about animations would be ideal. I've been searching for a while, and can't find anything on editing/creating animations for .WMO and .M2 objects.
-
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.
-
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?
-
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.
-
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?
-
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.
-
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?
-
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?
-
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.
-
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?
-
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.
-
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?
-
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?
-
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.