FiftyTifty
-
Content Count
28 -
Joined
-
Last visited
Posts posted by FiftyTifty
-
-
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
-
5 hours ago, Furioz said:To be honest i'm only sort of following what you are saying. But I believe wow does not use a colour palette. These .blp textures are converted .png files, you can easy convert one of these blp's with blpconverter's found on this website or install blpview to see these files in your windows explorer.
For particle's , some of the particles do use rgb codes to create particle colors.
And to create one of these texture files, is pretty "simple". If you know how to draw these you can make one yourself, although I am not much of a designer. But there are easy ways to recolor the blizzard blp and make items have an entirely different look.
As for example the warglaives
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?
-
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?
-
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.
-
1 hour ago, Serifaz said:Option 1:You would need to animate in mdlvis and convert mdx to m2 with mdx to m2 lazy Not recommended because verts rig only 100% no blend weighting.
Option 2: buy highlords tool for converting gltf into m2, Note: Rigging takes quite a while depending on how many bones you use, but it is a good tool.
Option 3: Wait for skarns blender studio to be released, most recommended.
NOTE: If you want to prepair a model in blender for conversion when skarns tool comes out or for when you buy gltf to m2, please keep in mind that you can not have a parent a bone to a bone that has a higher id than it. so this means if you parent a bone. make sure the bone it is parented to was made before the bone you are parenting.ps. if you need help learning to animate with blender pm me.
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?
-
On 7/29/2019 at 9:12 AM, Gratural said:Can be useful tool after adding few features:
1. Grouping all data rows by Light Params (each 18 strings)
2. Making text names of all parameters.
3. Able to adding and deleting data strings.
FiftyTifty, thank You! I'l Be waiting future additions.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
-
1
-
-
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.
-
13 hours ago, Mr. DK said:Hey,
cool you make a series. Really looking forward to this! Here are my twi cents:
For 10:- Steps how to aproach komplex WMO's (like a city)
- Changing komplex WMO's (like rebuilding Stratholm
General:
- Maybe a tutorial aboutAnimation
- Sculpting and Handpainting sounds interesting!
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.
-
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?
-
On 7/4/2019 at 1:13 AM, wungasaurus said:Regardless of the size - which is given in the header! - you can do such a button. Just move all stringblock bytes a bit to the back?
Pre db2, these files are utterly simple. It is just three blocks of fixed, header given, header given size, and the most complex part is that records can point into the string block. It is just completely dumb arrays.
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.
-
11 minutes ago, wungasaurus said:The client does automatically do some batching for static models. Detail doodads is a special and hardcoded thing. Without modifying the client itself a lot, adding more batching won’t be possible, it surely is nothing a designer could toggle.
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?
-
8 hours ago, wungasaurus said:String block size is for entire file, not per record. For that dbc it will be 1, as no column is a string. If it were, the record field would give an offset into the file global stringblock.
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?
-
On 6/29/2019 at 5:03 PM, wungasaurus said:Huh? The code on wiki is valid C++ except for the array lengths in dbc_file.
the WDBX code linked is not for dbc but db2. Header size is 5*4, I guarantee.
string block is a pure character dump that in the case of light will be always of size 1. it is used by columns that contain strings, where the field value is an offset into that block.
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?
-
12 hours ago, wungasaurus said:Oh, and if you think the wiki is too confusing even after you understood it, please reword stuff there, it is a wiki after all.
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.
4 hours ago, Gratural said:MyDBCEditor in 2019?! Open for yourself WDBX Editor!
https://github.com/WowDevTools/WDBXEditor
Dont make bicycle!) Speak with author about repository access.
If you can add some features (like multiple select, edit, replace and delete lines) - it be a wonderful!
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.
-
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?
-
1 hour ago, Gratural said:Classic procedural generated sky are, hardcoded. Can only change color and density.
For search (and change) any Skybox
1. See in Lightmaper Lightid for needed area.
2. Find this ID in Light.dbc
3. Remember Lightparams_0-3 (0-sunny, 1-underwater, 2-storm, 3 - underwater storm)
4. In LightParams.dbc see all this LightSkyboxID
5. And find him in LightSkybox.dbc
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?
-
4 hours ago, wungasaurus said:WMOs has both, own geometry and M2 based doodads.
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.
-
5 hours ago, Gratural said:See this (and all other from Amaroth) lesson
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?
Heightmap resolution <-> in-game map size?
in Level Design
Posted
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.