FiftyTifty

Members
  • Content Count

    28
  • Joined

  • Last visited

Community Reputation

2 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. 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.
  2. 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
  3. 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?
  4. 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?
  5. 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.
  6. 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?
  7. 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.
  8. 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
  9. Version 1.01

    232 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.
  10. 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.
  11. 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.
  12. 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?
  13. 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.
  14. 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.
  15. 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?