3D Model Viewer

[Hantoo]

For the last time, nothing was removed from the viewer (in fact, new things were added), however there is no UI for anything.
If you want something old or new to have UI, suggest how to make it.
I attached an image with a possible new client, that works kind of similarly to the world editor, in regards to adding new units.

If all you want to do is complain, go away.

Not Really Complaining, I can use the Old Viewer to do that
It just more like wondering if you forgot anything, Hope you don't mind

 

[GhostWolf]

That was not directed at you specifically.

Either way, if anyone wants that new client to exist, you better suggest how to design it.

 

[Fingolfin]

I am happy with the simplistic viewer as it is, i only wish that it would support more of the standard wc3 features. I noticed that General Frank's drumfire tank does not properly display the animated alpha of the material layers. Also, the glow particles in the death animation of some of my ships still doesn't properly animate, which i assume is related to animated particle visibility or animated emission rate.

 

[GhostWolf]

There are issues with the animation keyframe selection function.
It isn't clear how to make it work properly, so some models get such failures.
I've tried fixing this in the past, however I have no idea how to do that.

Art Tools mentions this:

If there are no keys on the first and last frame of a sequence, the default position, frame 0, will be used.

However, it isn't clear what "frame 0" is, and using the default values (e.g. [0, 0, 0] for translation, [0, 0, 0, 1] for rotations, etc.) doesn't work in all cases.

/Edit

I tried something a little different this time, but I am not going to test hundreds of models, so if anyone notices animations messing up...

 

[Ralle]

I tried to answer this, but it makes no sense to me. Wouldn't you always have a keyframe at least in the beginning of an animation?

 

[Deolrin]

Most likely this means the 'Stand' animation, which starts at frame 0 most of the time. Just copy the keyframes from frame 0, I suppose. I could be wrong.

 

[GhostWolf]

Most likely this means the 'Stand' animation, which starts at frame 0 most of the time. Just copy the keyframes from frame 0, I suppose. I could be wrong.

There isn't always a keyframe at frame 0, nor is any sequence forced to start at frame 0.

So far I tried with default values, the values of the first keyframe (whatever frame it's in), the first keyframe in the current sequence, what Magos did, and all of them don't work properly.

Right now it's the first keyframe in the current sequence, unless there is something at frame 0, in which case it takes priority.

 

[Deolrin]

Well, it should always prioritize the current sequence - I thought that the whole question was "what to do when the current sequence has no keyframes on its starting frame"?

 

[GhostWolf]

Well, it should always prioritize the current sequence - I thought that the whole question was "what to do when the current sequence has no keyframes on its starting frame"?

I don't even know what you want to say...

 

[Ralle]

Is it just me or does this model only work in the old viewer?
http://www.hiveworkshop.com/forums/models-530/deathwing-200374/

 

[PurgeandFire]

Is it just me or does this model only work in the old viewer?
http://www.hiveworkshop.com/forums/models-530/deathwing-200374/

Same issue on my end. Gives:
"Uncaught TypeError: Cannot read property 'frame' of undefined"

 

[Wasabee]

Is it just me or does this model only work in the old viewer?
http://www.hiveworkshop.com/forums/models-530/deathwing-200374/

Same here too.

 

[A Void]

4 me its works fine.

 

[GhostWolf]

I fixed it.

 

[Archian]

I fixed it.

 

[Wasabee]

New Model Viewer

Hello Hive staff!

Well I'll post it here because the model viewer seems to have a problem.

I tried to view this model and then this was shown:

New Viewer

It's just burnt texture and then I tried using the old viewer and it displayed properly.

Old Viewer

 

[Ralle]

Hey apcrabnightlive, thank you for the feedback. I will merge this thread into the other model viewer thread in just a sec.

 

[Fingolfin]

I have an idea - is there any chance we can have a model viewer for the skins section aswell? So that you can see how the skin will look on the model in 3d? It should be pretty straightforward, since the texture path is always specified in the post.

 

[Wasabee]

Well your suggestion is good since it's hard to view it with just screenshots.

 

[Ralle]

It is possible. It is also a good idea. I will put it on my list.

 

[GhostWolf]

I have an idea - is there any chance we can have a model viewer for the skins section aswell? So that you can see how the skin will look on the model in 3d? It should be pretty straightforward, since the texture path is always specified in the post.

This has been requested many times by now, and it's a part of the reason I added a generic texture rendering function (albeit less generic than it should be).
It shouldn't be hard to make a simple texture model, although the main issue, as it always was, would be to resize the model based on the texture size (since it isn't known at load time, and callbacks are meh...)
Though I must admit I am really not in the mood of doing this, or tracking the texture issue above.

/Edit

Just realized you mean applying a custom texture to the model it's meant for, that's up to Ralle, it's already possible and quite easy to do as far as the viewer cares.

 

[Ralle]

Right. If I have a say in this, your goal (when you feel like it) should be to make the viewer as correct as possible. Over time, I will do the rest.

 

[izaiphovias]

The viewer is not displaying this model properly: http://viewer.hiveworkshop.com/?q=154837

The model itself works just fine when downloaded

 

[Eagle XI]

It either wont load or loads extreme slow for me, old viewer functions normally.

 

[GhostWolf]

That model is displayed perfectly fine for me.
As I keep repeating in almost every page in this thread, if you have issues, press F12 to open the console, and report if you have errors there.

 

[Deolrin]

Define perfectly fine, please. The model loads for me but his face and the glow around Frostmourne are yellow.

I'm getting this error:
http://prntscr.com/7m3f61

 

[GhostWolf]

Yes, I saw that it was BGR instead of RGB yet again.
That error has nothing to do with the viewer, favicon.ico is just the silly icon you see next to a site's address.

If you want a better reply, don't report "The viewer is not displaying this model properly"...
As to "It either wont load or loads extreme slow for me", works fine for me.

 

[Deolrin]

Still, I think something is amiss.
http://prntscr.com/7m9zme
This is how it should look, I believe.

 

[GhostWolf]

Restructured a part of the MDX handler.
This should make the code neater, and fix both of the above problems (layers rendering when they shouldn't, and the red and blue channels being swapped).
I didn't do too much testing beside the above models, so if you see the same issues in other models, report them.

 

[PurgeandFire]

This model:
http://viewer.hiveworkshop.com/?q=266895
Error:
Uncaught TypeError: layer.setMaterial is not a function

 

[GhostWolf]

Fixed.

 

[GhostWolf]

I was testing stuff around and making an editor-esque client, and suddenly noticed that *big surprise* the keyframe insertion still isn't working properly (noticeable models: water elemental, lots of buildings not rendering when they should, and probably many more).

Can someone just reverse-engineer the game already and figure how it's supposed to work?

(on a side note, cleaned the MDX handler quite a bit, and optimized it a little)

 

[Dr Super Good]

Can someone just reverse-engineer the game already and figure how it's supposed to work?

It uses Direct3D 8. So however it works it works with practically the earliest shader standard available.

On a more serious note this should mean that the game has shader files somewhere. Although modern games such as StarCraft II provide the shader source code and compile on demand (with local caching for speed) to allow for better optimization older games might have provided pre-built shaders for use. If one can find those files one should be able to reverse engineer the shaders used by the game.

Obviously this does not give the entire picture (how the shaders are setup and run by the game) but it would at least give you something instead of having to guess.

 

[GhostWolf]

What? I am talking about logic, not rendering.

The one hundred dollar question - what to do with sequences that lack a starting or ending keyframe?

 

[GhostWolf]

Did tons of refactoring and probably introduced lots of new bugs, yey!
Except for bugs, you are not likely to notice anything.

Here's a new fun(?) demo client to compensate.

 

[Ralle]

I love this demo client. It is so cool!

 

[moyackx]

I love this demo client. It is so cool!

Nahh!!! it's too alpha

 

[GhostWolf]

The main issue with performance for MDX files is the sheer number of nodes.
I have no idea why even simple models tend to have over 40 nodes, but some models like the human knight have more than 200 nodes.
I can't think of any way to optimize node updates, so instead I added the option to change the frames per second of the whole simulation with frame skipping.
The default is now to skip 1 frame, meaning rendering is as always running at 60FPS, but the simulation runs at 30FPS.
As far as I can tell this isn't visible, yet it makes the simulation take far less CPU resources.

I will be glad to hear of ideas of how to properly optimize node updates (but I honestly don't think there is a way to optimize them).

Quaternion interpolation was changed from slerp/squad to nlerp/nquad.
This results in lower quality interpolations, but it's much faster, and generally can't be seen (unless you have quaternions with really big angle differences, which you shouldn't have in the first place).

Optimized particle emitters 2, ribbon emitters, splats, and ubersplats, to have shared buffers on the model.
No matter how many instances exist, only one copy of the buffer exists (same as geosets).

These changes and the above notice of bugs aren't yet in the generic client.

 

[Ralle]

Are you doing this to make it more able to handle multiple models in one scene?

 

[GhostWolf]

Yes.
This is much less of an issue for normal models, but WC3 models tend to just have a ridiculous amount of nodes for very simple things, and I can't think of a single way to optimize node processing (no SIMD in JavaScript yet )
The only practical thing would be to use web workers, but I am not sure if it will actually be good in this case.

/Edit
Implemented a demo bugged webworker animator, and it does seem to offload a lot of the CPU resources (since it is most likely using a real hardware thread), however it makes adding instances really slow, because it needs to serialize a lot of data in order to send it to the worker.
Most of the slowdown can probably be circumvented by redesigning the data structure of nodes and animation data, I'll see if I'll bother implementing it.
At this level of optimizations, basically object oriented code needs to be abandoned in favor of data oriented code, which isn't actually hard, but it's just a lot of rewriting the same code (it's starting to feel like I am a human Emscripten).

 

[Dr Super Good]

Why are we worrying about performance in a JavaScript model previewer? As long as it reaches 30 FPS or more on most systems I think it is fit for purpose.

If you want performance (eg for a game, or needing many of them shown at once) then you could try translating the mdl data into something more computationally friendly with what you have, even if it costs accuracy to some degree.

 

[GhostWolf]

The performance issues aren't really related to the format, but rather to what seems like simple abuse.
I have no idea why every model has so many nodes, and like I said, that's the part that costs the most (this is split between getting keyframe data (and this was mostly due to quaternion squads, which is why I changed from spherical interpolation to linear), and updating the local and world variables of the nodes).

It isn't important, and in fact neither are the gazillion optimizations I added over time, but it's nice to be able to view 200 models without freezing the browser (I wonder how Warcraft runs with thousands of units without lagging).

Also, as you can see in the arbitrary clients I make for fun from time to time, you can do a whole lot more than just preview a single model.

In other news, I still didn't manage to make a non-buggy web worker skeleton, for some reason it keeps messing although it has the same logic as the normal skeleton (thread synchronization???), however I got the initial hiccup of sending data to the worker to take about 0 milliseconds instead of whatever it was before that lagged the browser horribly.
Yey for data-oriented code.

 

[Dr Super Good]

(I wonder how Warcraft runs with thousands of units without lagging).

It does not. Place 1,000 units on screen and enjoy the single digit frame rate and possibly the sloshy mess of polygons floating around.

It only deals with models around the view area of the camera. As such thousands of units is less of a problem as only 50 or 100 might get rendered at once on an average map (and if more are rendered <60 fps is to be expected).

I am not entirely sure what a node is. But it is possible that WC3 does something to process them more efficiently than you are doing. Or maybe it just takes advantage of the extra speed native code gives (it is as slow, but executes faster than your implementation). WC3 is an old game and so maybe the complexity which is problematic now was less of a concern back then as there were other bottlenecks (like the GPU performance itself being bad back in 2003 odd).

 

[GhostWolf]

A node is equivalent to a bone (although doesn't necessarily have geometry affected by it).
That is, a part of an hierarchy that represents a skeleton.
Updating nodes means traversing the hierarchy and updating each node's local transformation data (location, rotation, scale => local matrix), and, using the parent node of every node, the world transformation data (world location, world rotation, world scale => world matrix).
The world matrix is what ends up being multiplied with vertices when rendering.
As you can imagine, this results in lots and lots of vector and matrix operations every frame (granted, this is where native code would be a great win, even more so with SIMD).

As to WC3, I remember playing maps with many hundreds and more units on the screen at the same time without lagging.

 

[Ralle]

How about just parsing the MDX in the web worker? That way you wouldn't have to serialize a lot of structures.

 

[GhostWolf]

That would require to serialize much more data. I thought about splitting the parsing in two, but I am not sure if this is worth the effort.
Changing the OOP nature of the nodes was the easiest thing to do in the meantime (didn't bother with keyframes and such yet).
All of the node data is shared in a single ArrayBuffer object, which can be passed to a web worker with virtually no cost. You can think of the shared nodes as an array of structs in C - it's basically casting a chunk of memory into an array of objects.
The real issue, assuming I fix the current weird buggy behavior, is that there are some structures that need access to the nodes (mostly all of the emitters, but also attachments, and attaching instances to the nodes of other instances).
This means that some data still must be shared.
I can probably use a second buffer for this, but it wouldn't be nice code-wise, because unlike C, I can't just cast the buffer into an array and be fine with it, the code will need to keep reconstructing the shared node objects every time (or otherwise, all accesses will be low-level memory accesses, which will be really ugly!).

The ideal way would be to split the whole handler into two - simulation and rendering.
All simulation (updating the skeleton, spawning particles, etc.) data and logic will run on 1-n web workers.
All rendering data and logic will exist on the main thread.
Sharing data between them will always use buffers (skeleton world matrices, particle emitter buffers, node data, etc.), which have near zero cost.
This requires to rewrite most of the handler though, and write code that will look far less like Javascript and far more C-like.
I never thought I'll be thinking about changing Javascript code to use a multi threading paradigm, it's odd.

I'll experiment with this and see how it goes.

 

[Dr Super Good]

As to WC3, I remember playing maps with many hundreds and more units on the screen at the same time without lagging.

It is surprisingly hard to fit 100 units on screen. Doodads and destructibles are usually less complex so are probably easier to render so do not really count.

The average WC3 Melee had well under 100 units per player in total, and that was what WC3 was designed around. maps which usually involve hundreds of units per player often end up a lag fest, be it graphically (too much happening on screen) or computationally (too many attacks/triggers per second).

I know for a fact that if you put too much stuff on screen it will cause the graphics to become garbage. As you can see here...

To clarify the image, all those shaded spots are individual Tauren Chieftain unit shadows. They are all the same yet past a certain number that kind of weird stuff happens.

I am unsure if this is a specific graphic element which causes problems, or if it is general. However I do know that Tauren Chieftain is notorious for causing this in huge numbers and have seen it in many spammy TDs and hero defenses.

 

[GhostWolf]

First very early and boring WIP of the new MT (multithreaded) branch.

It's mainly a proof of concept, nothing interesting to see.

It renders (albeit with no animations, textures, or anything worth looking at) 40 peasants, 40 militia, 40 footmen, and 40 knights.
It doesn't actually fetch animation data yet, but it does update the nodes, hence making it proof of concept, since that's the most expensive part of the viewer.

It uses N/2 workers, where N is the number of cores on the client's CPU (assuming your browser is updated and the number of cores can be read, otherwise there is always 1 worker).

Note that instances can't be split between workers, only models.
For example, in the above test, if you had 4 logical cores = 2 workers, all of the peasants would update in the first worker, all of the milita in the second worker, all of the footmen in the first one, and all of the knights in the second one.

Generally speaking it seems to run at 60FPS (even in Firefox!) with far less effort than the normal branch.
It does keep spiking, but that's actually because of the garbage collector, since I keep allocating objects.
After simple allocation optimizations (which I did also in the normal viewer multiple times in the past), it would be stable 60FPS.

There are a couple of logical issues, mostly related to data sharing, since data in web workers can't be accessed directly in the main thread, and vice versa.

 

[Dr Super Good]

Is it supposed to look like this? Not sure if it is working or not (IE 11). It is reporting no errors so I assume it is.

 

[Ralle]

GW, this is so cool, but I just want to clarify that at least my use case is not limited by the current implementation. I know you are a hacker and want to make it better, I just want to say that .