View in 3D

[JesusHipster]

Is squirt used anywhere? in the thread you posted, a user said it means that all the particles shoot at the same time.

Squirt is used in my cannonball model once again. I don't realy understand what it does, but in the end effect become more smooth and neat:3

And your veiwer still shows tailed particles with minus in it (once again, the cannonball) wrong.

E: turns out i can't see tail particles anywhere, but in the test model, sorry for a wrong feedback

 

[Ralle]

GhostWolf are you looking for a specific block in all Blizzard models? I can make a search quite quickly if you need it.

 

[GhostWolf]

GhostWolf are you looking for a specific block in all Blizzard models? I can make a search quite quickly if you need it.

Any chunk not handled by the parser, but that requires to actually parse them (since they are track chunks that are children of other chunks).

Then again, I would imagine a simple search for 4 bytes that form the text "KP2*" (where * is a letter) would suffice.

If something other than KP2V, KP2E, KP2W, KP2L, KP2N, KP2S shows up, it can be investigated.

By the way, this isn't important at all, I am just wondering if Magos mistakenly made his UI completely wrong, or if he made it right but ended not implementing these keys.

 

[nGy]

About Squirt:

Squirt – When the Squirt option is checked and an animated stepped Bezier controller is used on parts/sec, a large number of particles will emit simultaneously on the parts/sec keys in the amount of the key value. This is good for explosion effects.

If there is no animation in the particles/second, squirt will prevent the particles from showing.
I don't know, how frequently it's used though (I never use it myself) :/

 

[BlinkBoy]

I know WC3ME doesn't handle those keys (I looked at the source), I asked if you know about models that do have them.
But, of course, that's pretty stupid of me, because you wont know since WC3ME doesn't support them and thus you can't check if a model has them.
To know if they are keyed, one would need to parse all the original models from the MPQs...not worth the effort (not that it's hard, but if they can't be used by custom models, it wont matter in the first place).

I'll play some more with tails.

Thanks for your efforts!


Yeah I made a really silly mistake in the particle rendering, sizes should be correct now.

Or hack into game.dll:

Here's the implementation in NeoDex so you know which values are which.

writeMDXAnimateableParameter sub.speed  0.0 "KP2S" animations writeMDXFloat
			writeMDXAnimateableParameter sub.variation 0.0 "KP2R" animations writeMDXFloat
			writeMDXAnimateableParameter sub.latitude 0.0 "KP2L" animations writeMDXFloat
			writeMDXAnimateableParameter sub.gravity 0.0 "KP2G" animations writeMDXFloat
			
			writeMDXFloat sub.lifeSpan
			writeMDXAnimateableParameter sub.emissionRate 0.0 "KP2E" animations writeMDXFloat
			writeMDXAnimateableParameter sub.length 0.0 "KP2N" animations writeMDXFloat
			writeMDXAnimateableParameter sub.width 0.0 "KP2W" animations writeMDXFloat

In the modeling & animation forum there's thread with all the hidden tags.

 

[GhostWolf]

Thanks. There wont be any models with gravity keys, but it's nice to have it for completeness' sake.

That list lacks visibility keys by the way (KP2V).

Made quite a few behind the scenes changes. The viewer should be a little more efficient, and take less memory, in addition to the file itself being smaller (which is really not important).
Tail particles have been badly supported for some time. They show up, but not like the game displays them.

 

[Deolrin]

There wont be any models with gravity keys

What does that mean?
There's a lot models with particle emitters that use gravitiy. D:

Also, will you ever implement geoset animation vertex coloring, or whatever they call it? You know, the ability for geoset animations to change the color of the model. It can also be animated and linear, btw.

 

[BlinkBoy]

What does that mean?
There's a lot models with particle emitters that use gravitiy. D:

Also, will you ever implement geoset animation vertex coloring, or whatever they call it? You know, the ability for geoset animations to change the color of the model. It can also be animated and linear, btw.

he's refering to animated gravity, particle emitters where their gravity starts changing after a while.

Thanks. There wont be any models with gravity keys, but it's nice to have it for completeness' sake.

That list lacks visibility keys by the way (KP2V).

Made quite a few behind the scenes changes. The viewer should be a little more efficient, and take less memory, in addition to the file itself being smaller (which is really not important).
Tail particles have been badly supported for some time. They show up, but not like the game displays them.

I noticed the viewer doesn't have capabilities for rendering the ribbon emitters, which are very used in hightech effects. I have some code for rendering them in neodex, it's not too clean, but it does the job. Maybe it could help you on implementing them.

 

[GhostWolf]

Also, will you ever implement geoset animation vertex coloring, or whatever they call it? You know, the ability for geoset animations to change the color of the model. It can also be animated and linear, btw.

Fixed.

I noticed the viewer doesn't have capabilities for rendering the ribbon emitters, which are very used in hightech effects. I have some code for rendering them in neodex, it's not too clean, but it does the job. Maybe it could help you on implementing them.

They are actually used? I thought they are non existent, like particle emitters (not 2).

Can you share that code?

 

[Deolrin]

Ribbon emitters are used all the time. And particle emitters 1 are also used occasionally, but rarely.

 

[BlinkBoy]

well that code is in maxscript and rendering in maxswcript is very different to opengl.

What'll do is write you a quick guide on how to render them and send you some pseudo code. I imagine you can handle the opengl part so'll just explain the geometry and emitting part.

 

[GhostWolf]

• Added a WIP of ribbon emitters.
• Animation and camera names are now alphabetically sorted.
• Added an option to view animations at different speeds (0.2, 0.5, 1, 2, 5).
  Don't expect emitters to work correctly in Fast / Very Fast. This is on purpose, since it would have required the viewer to take more memory.
• Some arbitrary behind the scenes changes that fix some bugs and make the viewer a little more efficient.

Should I bother implementing particle emitters 1?

 

[BlinkBoy]

• Added a WIP of ribbon emitters.
• Animation and camera names are now alphabetically sorted.
• Added an option to view animations at different speeds (0.2, 0.5, 1, 2, 5).
  Don't expect emitters to work correctly in Fast / Very Fast. This is on purpose, since it would have required the viewer to take more memory.
• Some arbitrary behind the scenes changes that fix some bugs and make the viewer a little more efficient.

Nice work on the ribbon emitters.

Should I bother implementing particle emitters 1?

If you can easily refactor your viewer to be able to render extra imported models, then go on, they are pretty simple. They just work in a little different fashion to PE2 and emit models (emit TGA does not appear to work). However, few people really use them. Since only NeoDex allows you to export them and Magos sometimes erase them when saving the .mdx.

 

[Ralle]

I know we've talked about this before, but the order of which things are rendered seems flawed to me. Nothing ever goes through the ground even though it looks like it is below it.

 

[GhostWolf]

I know we've talked about this before, but the order of which things are rendered seems flawed to me. Nothing ever goes through the ground even though it looks like it is below it.

I have written this before, it has to do with abusing the depth buffer.

The correct solution is to sort things, but there is just no way I can think of to sort MDX geosets, since they have no positions, and every vertex can be affected by any bone.

Things go through the ground, it is just that the ground is see-through.

I don't know how Blizzard rendered models, so I don't have anything better to offer.
Rendering always gets messy with blending.

 

[BlinkBoy]

why not make the ground always highest priority then?

 

[GhostWolf]

Blending isn't as simple as that. If you'd render the ground with the depth buffer enabled, it will overwrite pixels written by layers rendered with the depth buffer disabled, which are pretty much all blended types.
If I could correctly sort things it would all be solved (or at least be much less noticeable), but I can't think of a way to do that.

Tail particle positions and lengths are finally correct, thanks a lot to nGy. They still don't have the correct camera-facing orientation, but that's less important to me.

 

[BlinkBoy]

Blending isn't as simple as that. If you'd render the ground with the depth buffer enabled, it will overwrite pixels written by layers rendered with the depth buffer disabled, which are pretty much all blended types.
If I could correctly sort things it would all be solved (or at least be much less noticeable), but I can't think of a way to do that.

Tail particle positions and lengths are finally correct, thanks a lot to nGy. They still don't have the correct camera-facing orientation, but that's less important to me.

would you mind sharing the formulas for tail particles?

 

[GhostWolf]

would you mind sharing the formulas for tail particles?

L' = |V| * L

Where V is the particle velocity and L is the emitter tail length, and

P' = P - (L * 0.5)

Where P is the emitter position and L is the previous calculated value.

In practice the pseudo code is as follows:

// V is the particle velocity
L = EmitterTailLength * 0.5
Px = EmitterPx - L * Vx
Py = EmitterPy - L * Vy
Pz = EmitterPz - L * Vz

And when rendering:

Offsetx = L * Vx
Offsety = L * Vy
Offsetz = L * Vz

P1x = Px - Offsetx
P1y = Py - Offsety
P1z = Pz - Offsetz

P2x = Px + Offsetx
P2y = Py + Offsety
P2z = Pz + Offsetz

P1 and P2 then form the particle line, over which you make a camera-space rectangle with the emitter scaling property being the width of the rectangle (and this is where my code fails).

 

[BlinkBoy]

hmm, so if the speed is animated, the length actualy changes according to the speed in that specific frame, right? or I use the speed in the moment I create/span/recycle the particle?

 

[GhostWolf]

I don't know, create a model and test it.

Right now I do it on particle creation.

 

[BlinkBoy]

Okay, I'll try and see, need to check if gravity changes anything as well.

Btw test the rainbow ribbon emitters in MDX Format Discussion thread with your tool. check if they work fine. i can make any samples you need for testing as well.

 

[GhostWolf]

What rainbow emitters?
Do note that currently the viewer only works for models uploaded to the models section.

In an unrelated subject, can you think of any reason SuPa's abomination's stand animation bugs so badly in the viewer? I've been looking at it for quite some time and can't find a reason.

 

[BlinkBoy]

What rainbow emitters?
Do note that currently the viewer only works for models uploaded to the models section

hmm, you should have a debug mode for trying local files, but well let's see afterwards.

In an unrelated subject, can you think of any reason SuPa's abomination's stand animation bugs so badly in the viewer? I've been looking at it for quite some time and can't find a reason.

makes me wonder about your code in animation breaking. the answer should be in mago's source.

I know something related to quaternions but that's for 3ds max, maybe it could help. it turns out that if the dot product between 2 quaternions is not between 0 and 1, you must negate the second quaternion. Perhaps that could help.

 

[GhostWolf]

hmm, you should have a debug mode for trying local files, but well let's see afterwards.

I thought the same thing, and so:

• Added a way to view models from any MDX on the Hive.
  In the url, instead of q=ID, have p=PATH, where PATH is as follows:
  

  ../PathToMdx/file.mdx

  For example:
  

  http://www.hiveworkshop.com/model_viewer/?p=../forums/attachments/modeling-animation-276/127958d1375058123-mdx-secrets-discussion-parttestonribbon.mdx

Custom textures can't be viewed this way though.

makes me wonder about your code in animation breaking. the answer should be in mago's source.

I know something related to quaternions but that's for 3ds max, maybe it could help. it turns out that if the dot product between 2 quaternions is not between 0 and 1, you must negate the second quaternion. Perhaps that could help.

My code was so similar to Magos' that I just ended up copying his at the end, so I don't understand how his works and mine doesn't.
I am talking about handling keyframes and interpolations.

 

[BlinkBoy]

hmm the rainbow ribbon wasn't there, i'll upload it here then.

Hmm Magos uses DirectX's slerp function, while you use your own made, probably you missed something.

There's also something curious about how that file was made. He exported the model using Neodex 2, buit that model was animated using IK, the transformation into FK just creates Keys when some IK properties wouldn't be met on the FK representation. This means the generated quaternions are not necessarily Dot Safe (as I mentioned before).

I have another model with IK, perhaps you could try it:

 

[GhostWolf]

No weird problems with the villager as far as I can see, but I don't know how the animations should look.
http://www.hiveworkshop.com/model_v...1377209658-view-3d-fighting-villager-hero.mdx

As to the rainbow, should it all be the same color, or should every face have a different color?
If the latter, how does it work, interpolation between every two edges?

 

[BlinkBoy]

Import it in-game you'll notice instantly. The vertex color is animated, so the overall vertex color should change according to interpolations.

 

[GhostWolf]

I don't have WC3 installed.

Is it supposed to look like the first, second, or something else:
http://www.hiveworkshop.com/model_v.../128722d1377209878-view-3d-rainbowribbons.mdx
http://www.hiveworkshop.com/model_v.../128722d1377209878-view-3d-rainbowribbons.mdx

Huh...can't post the second link without vB ruining it...
model_viewer/dev/?p=../../forums/attachments/site-discussion-97/128722d1377209878-view-3d-rainbowribbons.mdx

 

[BlinkBoy]

well like the semi-link you left there. There's a little thing bothering me there, first the material is additive, black shouldn't show and the emitters are sepparated by 180 degrees but they apear as separated by 90°, hmm i also feel one emitter is not rendering correctly. Let's try a version with less lifespan.

 

[GhostWolf]

It isn't using the normal geoset shader, so it doesn't support the same features yet.

Like I previously asked, should I treat the ribbon mesh the same way as a normal geoset?
E.g. render multiple layers, team color, texture animations, and so on (basically use the material the same way I do for geosets)?

Seems to work fine:
http://www.hiveworkshop.com/model_v...128725d1377212620-view-3d-rainbowribbons2.mdx

 

[BlinkBoy]

It isn't using the normal geoset shader, so it doesn't support the same features yet.

Like I previously asked, should I treat the ribbon mesh the same way as a normal geoset?
E.g. render multiple layers, team color, texture animations, and so on (basically use the material the same way I do for geosets)?

Seems to work fine:
http://www.hiveworkshop.com/model_v...128725d1377212620-view-3d-rainbowribbons2.mdx

Yeah, but ignore tvertex animations and coordid

 

[GhostWolf]

Ribbons now render like normal geosets.
I assume the weird lines in the rainbow aren't supposed to show up.

Also stopped "using" normals. They were sent to the GPU together with the rest of the data even though the code wasn't doing anything with them.

 

[Ralle]

This is so awesome!
How about allowing for sending a map of the BLP paths? &textures=tex1|tex2|tex3 urlencoded.

 

[BlinkBoy]

You know it would be nice to have an stand-alone version of the tool, specialy if it had command line options, so it can be used by other tools, like NeoDex.

 

[GhostWolf]

It's probably possible by using V8/SpiderMonkey directly in C++, but it would also probably be easier to just write the whole code in C++, which I am certainly not going to do.

I might look at Lua and see if it has decent OpenGL bindings, we'll see.

/Edit

Lua doesn't seem to have any decent GL bindings.

 

[BlinkBoy]

Hmm if you would really like to do it. I could help you out if we set up an SVN in google.code or gitHub.

 

[GhostWolf]

It's not that it's hard or that I need help, I just dislike C++ from the bottom of my heart.

 

[BlinkBoy]

It's not that it's hard or that I need help, I just dislike C++ from the bottom of my heart.

Yeah I hear you man. The memory managing and limitations when using closures, really makes C++ a pain in the ass.

Send me the lastest build, I would like to try it on haskell when i get time.

 

[GhostWolf]

You have it already, that's where I write the code.

 

[BlinkBoy]

great, I'll try later to rebuild it's Class diagram, Use case diagram and sequence diagrams of the main module in UML and document it. Once I have redesigned, I'll select the language.

 

[GhostWolf]

This is so awesome!
How about allowing for sending a map of the BLP paths? &textures=tex1|tex2|tex3 urlencoded.

If you make a server-sided way to retrieve model/texture paths without writing the full ones, maybe.
Other wise you'd get ridiculously long urls.

• Ribbon emitters now render with triangle strips (less memory and bandwidth).
• Changed shader handling:
  1. Only shaders that are going to be used will be compiled.
  2. If a shader fails to compile, the things it is supposed to render just wont show, but the viewer will continue running.

 

[PROXY]

Just wanted to tell you that I reset my firefox and the viewer is working perfectly now.

 

[GhostWolf]

• Added support for particle emitters (type 1).
  But don't expect it to work with custom models (for the spawned models that is), since currently it can only load files from the WC3 MPQs.
  Here's an example (Death animation).
  I don't know if recursive particle emitters are allowed in-game (that is, particle emitters that spawn models which themselves spawn more models), but they are disabled for the viewer, since it will allow the creation of infinitely recursive models which will result in bad things happening (like driver crashes?).
• As the link above shows, you can now show any model from the MPQs with the mpq=PATH variable in the address bar.
• Added the option to view collision shapes.
  But only spheres and cubes so far.
• Fixed arbitrary bugs.

 

[Deolrin]

Awesome, but I think their orientation should be more or less random. I don't remember the Dragon death being quite so uniform.

 

[GhostWolf]

• Added support for CoordId.
  But there are no models to test this with.

Are there any features I forgot to implement?

 

[Deolrin]

Did you try implementing Omnilights? That'd be cool.

 

[GhostWolf]

How do WC3 lights work? (are they even dynamic?)

 

[Deolrin]

I have absolutely no idea.

 

[GhostWolf]

If you want lights you better know how they work. I could easily do something similar to Magos' lights, but that's not how WC3 looks.