Fan made projects related to MLP

Search /collab/ threads

Name  
Email  
Subject  
Message  
File     
Embed    
Password  (for post and file deletion)

File 138721493881.gif - (19.61KB , 100x108 , princess-twilight-flight-right.gif )
45984 No. 45984
It's been a whole year since the last thread. So I figured it was about time for a new one. (Old thread: >>43172). Related fun fact: Desktop Ponies is now 2 years and 8 months old.

Full download (v1.52 released 2014-10-06):
https://github.com/RoosterDragon/Desktop-Ponies/releases/download/v1.52/Desktop.Ponies.v1.52.zip

We've seen 20 new canon ponies and a bunch of extra animations since this time last year. As well as a wealth of other improvements.

Check out the deviantART community:
http://desktop-pony-team.deviantart.com

Also check out the OC thread for more ponies, and information about creating your own OCs:
http://www.ponychan.net/chan/collab/res/43607.html

Last edited at Mon, Oct 6th, 2014 10:34

548 posts omitted. Last 50 shown. Unspoiler all text  • Expand all images  • Reveal spoilers
>> No. 47398
>>47395
Well, this does require an explanation.
[TL;DR:] it`s implied by the current architecture. In case there is an alternative solution that I`ve overseen, feel free to describe a better architecture. Some of the probable solutions I already considered are listed below.


Hereinafter, «server» is a library responsible for loading and drawing, and «client» is an executable that tells the server what to load and draw.
To avoid confusion, let`s also define «animation» as an internal server structure whose data is unique among other animations, and «sprite» as a client-controlled instance of some animation on the screen.

Every animation has its unique ID. When it`s time to update the screen, the client has to set properties for every sprite, namely: animation ID, frame number and sprite position (X, Y). Sprite dimensions are not needed: both server and client know them, and they stay constant for every sprite rendered from the same animation. Then the array of properties is passed to the server, and the server feeds it to the shader program. When the execution reaches this point, the shader program needs to determine which animations are to be drawn, and all it`s got is an array of sprite properties and a pre-allocated array of animations. How to link sprites to animations, and how to store them rationally?

In GLSL 1.10, the input data passed to the shader can be either vertex attributes or uniforms — special variables imported from RAM to VRAM. Static arrays are possible, but the total number of imported uniforms is bound by GL_MAX_VERTEX_UNIFORM_COMPONENTS and GL_MAX_FRAGMENT_UNIFORM_COMPONENTS, both usually less than 1024, and much less than, say, a million. Vertex attributes, in turn, are given to the shader one vertex at a time, proving their name.
So, animation properties like width, height or scaling factor can not be stored in vertex attributes. Technically, it`s possible, of course, but it`s very impractical: they`ll have to contain several times more data than the number of sprites, since every sprite has several vertices (6 for the current implementation — 3 for both triangles comprising a sprite quad); what is more, the attribute array would have to be refilled on every sprite reordering and then sent to the GPU, along with the sprite properties from the client. Another point is that the total number of unique animations is quite finite, bound by the animation base on disk, unlike the number of sprites, which can be added or deleted every frame. Unfortunately, uniform arrays are also not an option, since their size is limited and largely depends on GPU capabilities: some early models supporting 1.10 had as little as 16 hardware uniform slots.
What`s left? The most promising (if not the only) option is textures. Consider a texture containing IDth animation properties in IDth pixel. This screme is not in any way affected by sprite ordering, so once loaded, these values hardly ever change. Thus, there`s no need to update the texture every frame wasting precious video bus capacity. There`s even a special texture type for that, called GL_TEXTURE_BUFFER, but it`s not available in 1.10, so let`s stick to the good old GL_TEXTURE_2D. So, acquiring the necessary data by animation ID would require a texel fetch.

And there`s the pitfall. Most computations that give pixel shaders the data they need are complex enough to slow execution down if done anew for every pixel. Furthermore, setting sprite geometry, the actual job of a vertex shader, requires knowledge of sprite dimensions at least, stored in a texture.
>> No. 47400
First of all, a quad has 4 vertexes, even after being converted to a pair of triangles. You aren't doing it right if you need to duplicate the shared vertexes.

Now, I do not get why the vertex shader needs to look up things like scaling and what not. That is the key point here. Why does the vertex attributes not contain the position of the vertex, both on screen (XY) as well on texture (UV)?

You might argue that the gpu doesn't need to be told the animation data each frame. But what it does need to be told is the position of the current animations and their status. Since as far as I know, there is no such thing as per triangle data, you have to either use multiple draw calls and uniforms (bad for performance) or let each vertex carry the data.

What exactly does the vertex attribute data contain in your setup? My setup has just four values per vertex, each unique: X, Y, U and V.
>> No. 47401
File 142100504300.png - (237.20KB , 545x491 , src+bin.png )
47401
>>47400
> First of all, a quad has 4 vertexes, even after being converted to a pair of triangles. You aren't doing it right if you need to duplicate the shared vertexes.
Uh, okay, mea culpa. I`ve got 6 indices for glDrawElements(), but actually 4 unique vertices, you`re right. At first, I used to have 4 indices when drawing GL_QUADS, but then I stumbled upon the official OpenGL wiki [www.opengl.org] that said it is no more standard. This usually means lack of hardware support, so I switched to GL_TRIANGLES.

> Now, I do not get why the vertex shader needs to look up things like scaling and what not. That is the key point here. Why does the vertex attributes not contain the position of the vertex, both on screen (XY) as well on texture (UV)?
Plain economy, both in terms of performance and bus capacity.
First, I use a 3D texture to store animation frames, so there are 3 texture coords: 2D textures are too small to store ~90 MB of raw pixel data in a single sampler object. (XY)(UVW) don`t fit in vec4, so we`ll need at least a vec2 and vec3 for vertex attributes. But that`s not the main point. The main point is that my approach gives me one «dynamic» vec4 per sprite, not per vertex.

This is how it works:
1. The array of sprite properties is also passed via texture and updated every frame using glTexSubImage2D().
2. The vertex attribute array is static and never changes.
3. For every vertex in this static array, left corners have X = 0, bottom corners have Y = 0, right and top have X = 1 and Y = 1 accordingly; Z = sprite property array index, same for every 4 consecutive vertices.
4. In the vertex shader, each vertex «knows» where to look for the new data, due to its Z coordinate.

Note that this approach does not require any per-frame computation to be done on CPU, since all data is passed unchanged. According to Amdahl`s law [en.wikipedia.org], this shall provide higher performance than what you proposed, and results in 4 times (5 actually, because of 3D texturing) less data going through the video bus at every frame.

The pic attached is a RARPNG containing full source at its current state and executables for both Win32 and Linux x64. To work properly it needs a copy of original DP «Ponies» directory near the executables, renamed into «anim».
core/ogl/shad/ dir contains actual shaders, core/ogl/oglstd.c has their comments.
>> No. 47402
So you are basically using vertex attributes and changing the texture instead.

I am not sure that it is a good idea to upload a new texture each frame. There is also the issue of overdraw.

Can you elaborate on what data exactly is stored in the texture? How much data needs to change in the texture each frame?
>> No. 47403
>>47402
Both shaders operate on 5 texture objects in total. 4 of them are static. The only texture that changes dynamically holds the sprite data, 1 sprite = 1 texel.
The exact layout for all textures is outlined in comments, see oglstd.c; they are quite large, you won`t oversee them. Still, here`s the structure of the sprite data texture.
Each texel is a combination of 4 single-precision floats:

R = X position of the sprite
G = Y position of the sprite
B = current sprite frame
A = [base index (22)] [Y inv (1)] [X inv (1)]

I.M.H.O., the only element worth explaining here is A. It is the actual sprite`s animation ID (22 upper bits) and its current mirroring (2 lower bits). For the purpose of minimizing RAM / VRAM footprint, all animation pairs that are mirrored copies of each other are stored as a single animation sharing same ID and differing in lower bits only.
As per IEEE 754 [en.wikipedia.org], floats have a 24-bit mantissa, 23 actual bits and 1 hidden. Thus, the largest integer that can be represented without losing integer precision consists of 24 bits, which gives 22 + 1 + 1.
>> No. 47404
>>47403
I fully understand now, quite clever.

The cpu has to compute four-ish values for each quad. The traditional approach is four values per vertex. This is four values less since you need four vertexes per quad.

But I still don't understand why you need the animation data to be stored on the graphics card. To me it seems more straightforward to just let the LUT texture contain data about possible frames to draw and nothing more. As far as I understand, none of the animations here need to do any scaling, tinting offsetting or other effect that would require more data for each quad than the UV of the image texture and the dimensions of each frame.
>> No. 47407
>>47404
> As far as I understand, none of the animations here need to do any scaling, tinting offsetting or other effect
They do. Unfortunately, they do.
There are several methods of minimizing the amount of pixel data RAM (and, most importantly, VRAM) implemented in my engine.
Among them are mirroring, scaling, transparency cropping and linearized pixel storage. The first technique has already been mentioned.
W.R.T. scaling, not every animation in DP base can be downsampled twice, and some of them can be downscaled 4-fold, which adds individual scaling factors to animations` properties. Compared with 4 and even 16 times less memory for pixels, this isn`t much.
Cropping also adds 4 individual values — the coordinates of the cropped animation inside the bounding rectangle of the original. Same reason.

Maybe the most interesting of technologies implemented is the latter.
The engine does not store frames as rectangles, like it`s usually done in textures. In our case, it`d be an awful waste of time and memory: animations differ both in size and in framecount, and the problem of arranging quads of depth 1 so they adequately fit in a cuboid is not only NP-hard [en.wikipedia.org], which is already enough to slow loading down, but also its solutions leave spaces. Such packing will also require a map that defines the exact position of each quad (frame), resulting in 3×framecount additional values per animation.
So, the engine treats frames` pixels as a 1D string of bytes, and animation data is written into the 3D texture string by string, also treating each layer as a very long 1D. This way, if provided with UVW coords of the first frame of the animation, the engine knows exactly where each next frame resides: base + W×H×frame_number. One notable exception is that frames are never split between layers because it would complicate pixel shader code. If the layer has less space left than required to store the frame, it`s allocated in the next layer.
>> No. 47420
File 142174293412.gif - (20.83KB , 106x106 , High Heel trot.gif )
47420
High Heel updated with shorter legs, second part of tail, etc. Also corrected the colours on Pharaoh Phetlock [fav.me].
>> No. 47427
>>47420
Nice :)
>> No. 47482
File 142242481804.gif - (18.37KB , 86x86 , sunset-idle-right.gif )
47482
Since I'm a sucker for making improvements to anything whether it's necessary or not, I made a few tweaks to Sunset's animations and especially to her mane, which has been bugging me for the longest time.

After all this time, it's now finally a bit more show-accurate! :D

I've also added some voice samples (so far only from the second movie) and deactivated some of her meaner or goofier lines (#3, #6 and #8 to be precise, just in case you want to re-enable them for some reason).

http://sta.sh/0azmcdo5nyf
>> No. 47484
I don't know if this has been discussed before, but is it possible to make an oc? or does anyone take commissions for this kind of thing?
>> No. 47485
>>47484
It has been discussed way too often before, but some people seem to prefer repeating the same questions over and over instead of just reading the information provided.
Here it is anyway: There is a thread specifically made for dealing with OCs. You can find a link to it in the first post of this very thread.
Also, our sprites and templates are meant to be used non-commercially, so no commissions.
>> No. 47492
File 142317912964.gif - (13.75KB , 92x106 , pinkie-dance-right.gif )
47492
This small update adds Pinkie's and Cadance's little dance from the wedding to both ponies.

http://sta.sh/01qamoamkuqz

And for the interaction, just add this line to the interactions.ini:

Wedding_dance,"Princess Cadance",0.1,200,{"Pinkie Pie"},One,{"weddingdance_start"},120
>> No. 47504
>>47247
>Not sure if it's been reported before, when using the screensaver on Windows 8.1, background is not transparent despite the setting being selected. However, it works normally in preview mode.

Yeah, I'm having a problem with this as well. Does anyone have a fix for this?
>> No. 47516
File 142484193541.png - (776.41KB , 1070x708 , 13741577828.png )
47516
Guys… guys, is it just me or is this epic thread eventually dying?
>> No. 47517
>>47516
I certainly hope not, but I have to agree that it doesn't look all that great at the moment. Hopefully, this will change once this ridiculously long hiatus is over.

Also, getting a few newcomers every once in a while might help to breathe some fresh air into the project, but you can't really force that. :(
>> No. 47524
File 142541537984.gif - (22.37KB , 64x174 , goldenhazel-idle-right.gif )
47524
Since there's a bit of a drought of new downloads here at the moment, I guess I may as well mention that there are a few new Equestria Girls available for download on my DeviantArt page:

http://sta.sh/2ouk6qgs0sg

Since the last time I've mentioned them here, I've added Atomic Adam, Wiz Kid, Scribble Dee, the Diamond Dogs (Rover, Fido and Spot) and Golden Hazel to the collection.
>> No. 47525
Ok so since I've been lazy for almost half a year I'm pulling together a new version with the extra ponies Bot-chan has made :P

Don't know if there's any fixes I have the know-how to make but I think I'll try and at least spice up the github page since now that's where all the downloads are sat.

>>47504
I don't have a fix for this sadly :( You could try setting a background image for the screensaver profile instead so at least you have something other than a grey area behind it.

>>47378
It might be a bug, but you could also try checking the options for the screensaver profile and see which monitors or what area the ponies are allowed to walk in. Maybe that are being restricted to one monitor right now.

>>47407
Seeing as I'm increasingly useless these days, do let me know if you get to the point where your system could replace mine outright. Forget the library stuff, I'll likely never be able to manage it.

>>47366
Glad to hear you fixed the boxes issue. Not sure about the CPU I'm afraid.

>>47336
Regarding speech text, I could tweak the font, colour scheme, etc a little bit if that's worthwhile. Rounded corners wouldn't be impossible either. If somebody can suggest a good design I'd be up for doing what I can to make it happen.
>> No. 47526
>>47525
Welcome back! *throws confetti*
>> No. 47528
DPE anon here.
It turned out that writing a grad thesis while working part-time is much harder than I initially thought. This is the reason for the lack of updates from me T_T
It`s worth to note that just working full-time leaves several hours more spare time daily.

>>47525
> Forget the library stuff, I'll likely never be able to manage it.
OK. I already made single-module compilation scheme the default, although it`s still possible to build the executable and the library separately.
> If somebody can suggest a good design I'd be up for doing what I can to make it happen.
This may just be yet another crazy idea, but have you thought of integrating a simple interpreted language (like, say, LISP or Forth, maybe Lua) into DP?
Scriptability can eliminate inner behavioral code altogether while allowing ponies to do much more, e.g. interact with the OS (tell the current time for Doctor, draw something random on the screen for Discord, fly from window top to taskbar for RD, hang from window bottom for Flutterbat). Of course, drawing (or just loading) custom speech bubbles would thus become designer`s task, not developer`s.
>> No. 47529
>>47528
That is no small feature, definitely a bit of a pipe-dream I think.
>> No. 47530
I am not convinced that it's a problem.

I think we can do plugins. I blindly guess that we have some class responsible for running each behavior. Let a plugin provide a replacement class.

Plugins would be done as DLLs that are loaded as specified in the ini files.

Scripting languages are overrated, what people actually need is to add code. There is no need for some complicated VM to do that.
>> No. 47531
I'm on a Mac OS X and once the Desktop Ponies zip file was expanded and I downloaded a version of mono, I went to run the RunOnMac.command for Terminal and it comes up with an error, "The Ponies directory could not be found. We can't start without that! If you just downloaded the full program then please make sure it has extracted correctly. On Mac/Unix it is important to preserve the directory structure when extracting. If you have downloaded a patch - you need to copy these files over an existing install and overwrite if prompted." I don't know why this is coming up. Help?
>> No. 47532
File 142609801249.png - (26.81KB , 595x350 , Desktop-Ponies-Folders.png )
47532
>>47530
I think there are more costs than just that, personally, and I can't justify the time to do it myself.

>>47531
I have attached a screenshot of what the folder should look like after you extract it. Notice the "RunOnMac.command" and the "Ponies" folder are both in here.

The error message you're seeing means the "Ponies" folder doesn't seem to be there.

Maybe that helps a bit?. If not, post a picture of what you have on your computer I might be able to help more.
>> No. 47533
File 142609970599.png - (262.80KB , 575x712 , Screen Shot 2015-03-11 at 11_47_43 AM.png )
47533
>>47532
None of the files are in folders.
>> No. 47534
Looks like the program that unzipped it did a bit of a cruddy job.

Somebody else had this issue on Mac too and had a suggested tool that worked for them, see the linked post:
>>46705
>> No. 47535
>>47532
Costs like what?

From my limited understanding it is just a matter of loading the DLL with the pony and doing a small tweak to the behavior initialization code to use the custom class instead.

The rest of the problem is left to the plugin author. Give them references to some useful objects, like say the pony in question and the speech bubble, and they will do the rest.
>> No. 47536
>>47535
The main problem, as I see it, is that artists and designers are not coders. They might not want to install an IDE or learn a build system to get DLL toolchain up and running, and then write actual code and compile it. Furthermore, Win32 is not the only platform for DP.
So, the only option I see is to have a built-in JIT and a «standard library» script containing default actions (like following a pony or changing movement direction) that can be called in a response to some event.
The more advanced, personalized set of actions for a pony shall be a result of coder/designer cooperation.
>> No. 47537
>>47536
To add to this, the existing system isn't designed in an easily extensible manner either. It's not ready for external stuff to come along and mess with it - hell it's only just capable of managing itself without getting in a twist.
>> No. 47538
>>47536
Scripts are coding. It is going to be too difficult for non coders no matter if you hand them a scripting language on a platter or just the same language as what the main program is written in.

You are correct in that this would require designer/coder cooperation, but I know that's easy.
>> No. 47539
>>47538
I stated the presence of some standard function set for a reason.
As for now, DP designers have a special tool that helps them create new characters without the need to write configs manually. The standard script (coupled with some changes to the tool) shall serve exactly the same purpose. Provided with default functions, the tool will automatically generate behavioral scripts for any subset of standard actions chosen by the designer.
The key difference from what we have now is that these scripts can be easily extended and distributed by a coder, without the need to recompile DP core.
>> No. 47540
>>47534
It worked! Thank you!
>> No. 47541
>>47539
The same benefit applies for plugins. No need to recompile the core.

And a "standard script" is nothing more than a specific API. Plugins would need one of those too. But they have the benefit of just being able to use the existing classes. So there is less work to use plugins, since there is no need to integrate a jit engine as well as write an API for the scripting, just use what already exists!

It's just loading an additional file at runtime, something that's like a function call or two. Quite a lot less than a full separate engine.

And really, if someone isn't able to recompile the core, then they don't have the skills to write a script either.
>> No. 47543
I can only imagine that I had a good reason for not finishing them earlier. Unfortunately (or not), I can't remember it, so here are all of the Mane-iac's henchponies. :)

http://sta.sh/01xwowwmuztj
>> No. 47545
Hello!! I just downloaded and im wondering how to use this!! thanks!!
>> No. 47546
>>47545
Firstly, what OS do you use?
— Windows: just run Desktop Ponies.exe from the program`s main folder.
— MacOS X: execute RunOnMac.command (also in main folder).
— Linux: the exact way to run largely depends on what distro you use, so please specify it first if this is the case.
>> No. 47548
Bulk Biceps/bulk_lift_left.gif, Bulk Biceps/bulk_lift_right.gif: transparent pixels in the corner of Fluttershy`s right eye.
>> No. 47549
File 142691878930.gif - (18.51KB , 80x88 , doctorhorse-trot-right.gif )
47549
The doctor is now ready to make some house calls.

http://sta.sh/021f96tqoih

>>47548
Good catch. I've included the corrected sprites with the Doctor Horse download.
>> No. 47550
An idea: can we adjust the animation speed to match the movement speed? That would allow some nice reuse without making ponies look like they are sliding around.
>> No. 47551
>>47550
Assuming that normally they are in sync, yes. Given an arbitary R, multiplying the movement speed by R and frame delays by 1/R shall result in R times acceleration.
Still, what exactly do you mean by reusing?
>> No. 47553
>>47551
Just reuse as in not needing to duplicate animation data, be it in memory or as files on disk.
>> No. 47554
>>47553
I understand what reusing means. And yes, it`s possible. I just don`t get why we might need to create new sprites with adjusted speed; I can`t see the usecase. There already is a global multiplier called «time dilation».
>> No. 47556
>>47554
Note how you say "sprites" when I say "animation data". They aren't the same.

When you say "global", what do you mean exactly?
>> No. 47557
>>47556
> Note how you say "sprites" when I say "animation data". They aren't the same.
Exactly. They are just the opposite. «Sprites» = «not needing to duplicate animation data» (see >>47398).
> When you say "global", what do you mean exactly?
Applied to all sprites on the screen.
>> No. 47558
>>47557
I was afraid that you meant that. A global solution wont work for this. But the underlaying code might make it a lot easier to do this.
>> No. 47559
>>47558
OK, but what was your idea?
>> No. 47560
>>47559
Didn't I state it already? Scale the animation speed to the movement speed.
>> No. 47565
I searched google for a way to get the program to display ponies on startup without having to click the Give Me Ponies button on the menu
I read some stuff about an autostart option or naming a profile to "autostart," but that hasn't worked. Is there a setting that needs to be changed to get it to work? The pages also talked about doing something from the command line but I have no idea how to do that.
Help please!
>> No. 47566
>>47565
Ok so I'm going to provide instructions for Windows and hope that's what you're using. :)

- Load Desktop Ponies and create a profile. To do that, select which ponies you want to use in the menu. Then in the bottom-left enter a name for your profile in the 'selected profile' box and hit save. Then close Desktop Ponies.
- Create a shortcut to "Desktop Ponies.exe".
- Right-click the shortcut and choose 'Properties'.
- There should be an entry for 'Target'. This will have the path to Desktop Ponies in it. e.g. It might be "C:/Blah/Desktop Ponies.exe".
- Here is where you can set it up to use autostart. Let's say you named your profile 'ponies'. Add autostart ponies to the end of the 'Target' field. Overall it might now look like "C:/Blah/Desktop Ponies.exe" autostart ponies.
- Apply these changes.
- If you click the shortcut, the program will open and load your profile right away.
- To run Desktop Ponies at startup, place the shortcut in the Startup folder. There's instructions here: http://windows.microsoft.com/en-gb/windows/run-program-automatically-windows-starts

That should do it - let me know if you have any problems.

Last edited at Thu, Apr 2nd, 2015 18:28

>> No. 47568
I've released 1.53 - woo.

New thread >>47567 since I can't edit the parent post any more (let that be a lesson in never forgetting your login details kids).

See you there :)
[Return] [Entire Thread] [Last 50 posts] [First 100 posts]


Delete post []
Password    
Report post
Reason