Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Work in Progress / jGpuSkin - Skeletal animation plugin for DBPro

Author
Message
Chris Tate
DBPro Master
9
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 9th Mar 2018 13:26 Edited at: 9th Mar 2018 13:31
I am thinking about what could be causing this shadowing problem occuring on the neck of the model I am working on. Once permutation matrix applied and flipped normals have been applied, everything is rendered correctly except the neck.

It looks to me that somewhere along the line between export from Blender, via Fragmotion to the import tool; the ordering was interpreted to the point where the normals in the neck and head area are in reverse on the Y axis.


Current problem

Current problem, shadow on one side for the torso, then the reverse from the neck up

Current problem from the rear

Blender display of the source

Fragmotion seems to display the same shadow

Working model, the low poly version supplied with the plugin. Same structure. In your import tool.

The final version is the low poly model I gave you for the plugin with a permutation matrix applied.

None of the normals were altered in Blender. I use Flip normals on X and Z in the plugin. Frag motion seems to display a similar shadow on the neck area; it could be at fault.

Any ideas what might be the cause?
Ortu
DBPro Master
10
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 9th Mar 2018 16:33 Edited at: 9th Mar 2018 16:35
The message notification count has been broken for a while, I have started to check in to my box regularly even if it is showing 0.

I keep my skeletons on a separate layer from my character mesh also and have not encountered an issue with export / import into dbpro. Im not using this plugin, but Blender does export the bones on a separate layer as long as it is active and selected

The shadow issue is odd. It doesn't look like you have a normal map applied in that shot, do you? That can override the geometry normals and create strange shadows, particularly if you are using any mirrored UVs, but I think something else is going on here. Not sure what...

Was that side of the head created as duplicate + mirror of the other side? In blender this will invert and set the mirrored geometry to a negative scale. This is why you have to flip normals after mirroring,
But while that makes it look correct in blender, it doesn't actually fix the inverted scale issue.

(The mirror modifier does not suffer from this, but if you did ctrl D + ctrl M within the mesh in edit mode strange things like this can happen)

You might try Ctrl A -> apply scale, recalcute normals, then try the export again.
http://games.joshkirklin.com/sulium

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
Chris Tate
DBPro Master
9
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 9th Mar 2018 17:38
Quote: "The message notification count has been broken for a while, I have started to check in to my box regularly even if it is showing 0."

Oh ok.

Quote: "I keep my skeletons on a separate layer from my character mesh also and have not encountered an issue"


Hmm. You might be running a newer export script than I am; DBP and the import tool were only able to view my model correctly after I placed it and the mesh in the same layer. I'll soon have this figured out.

Quote: "The shadow issue is odd. It doesn't look like you have a normal map applied in that shot, do you? "


Besides the blender screenshot; no normal map is applied, just a texture-less mesh. There are a number of things which I will need to inspect, such as my modifiers and the differences between my previous character versions. This was not a problem 3 months ago.

Quote: "(The mirror modifier does not suffer from this, but if you did ctrl D + ctrl M within the mesh in edit mode strange things like this can happen)"

I quit using the mirror modifier about a year or two ago because the old me got fed up with having to mirror vertex groups and uv coordinates all of the time; the new me would have kept it and looked into the documentation a little more; but the job is pretty much done for the pre-releases. I'll most likely start a new batch of models for final release or an expansion.

Quote: "
You might try Ctrl A -> apply scale, recalcute normals, then try the export again."


I'll give that a shot
revenant chaos
Valued Member
11
Years of Service
User Offline
Joined: 21st Mar 2007
Location: Robbinsdale, MN
Posted: 9th Mar 2018 18:08 Edited at: 9th Mar 2018 18:09
Hi Chris,

I'm not sure why that would be happening, it seems Fragmotion does some strange things with vertex normals. Luckily Ortu beat me here with some actual advice. If his suggestions don't solve the issue, the best I can think of off-hand would be to add a tool to the importer for re-calculating the vertex normals (something I should probably do anyways).

On an semi-related note, I've noticed some strange issues with the indexdata your exporter is producing. The vertices are indexed, but the indices aren't anywhere near optimal. Calling dbpro's Set Object Normals command on your objects results in faceted normals, as if the indexdata doesn't exist. My personal normals calculation code outright crashes. The importer's Weld tool is able to re-index the vertices in a much more optimal manner, afterwards recalculating normals works as expected (Both mine and DBPro's).

@ Ortu - Thanks for chiming in here man, your advice is greatly appreciated.
Chris Tate
DBPro Master
9
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 10th Mar 2018 03:04
Thanks, I will see how I get on will post the results.
Chris Tate
DBPro Master
9
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 10th Mar 2018 08:55 Edited at: 10th Mar 2018 09:15
OK. Progress so far; flipping the normals in Blender worked as expected, it just looks like the Direct X exporter has screwed something up, as was suggested yesterday.


Upon performing a first test which involves using SET OBJECT NORMALS in a DBP app; I loaded the altered model into the editor directly, which lead to the usual X rotation discrepancy, only the character's head became the right way up. This is not because of the set normals command, because the same is true of the original exported .X file. This should be a clue as to what has changed.


So here are the images of the import tool without using Fragmotion to convert. The .X version would produce the same result, that is without using SET OBJECT NORMALS, resulting with smooth edges, but again; with the head upward, stretched away from the body.

Very wield looking



The same with Perumutation. No frag motion. If I did not use the SET OBJECT NORMALS command, it would look smooth



Here is the same model loaded into Fragmotion




And finally in the import tool with the fragmotion export.





(The eyes are not in the head, far from it... something I will look into next)

I'm thinking I am going to for now, I will try to find quick fix solutions, smooth out the normals in the editors and produce the best I can.

Then the long term solution is to find a Python programmer to improve the export script, and perhaps write a DBO export script.

[EDIT]

It looks like Set Normals cannot be used because this messes up the bone animation.

Now trying Frag motion's normals tools.
Ortu
DBPro Master
10
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 10th Mar 2018 14:56
What version of blender are you using by the way? The .x exporter changed quite a bit between 2.49 and 2.50 on.

I had to make changes to get the newer version to work with Sparky's (though that then broke animation so I run one version for static collision exports and one for animations)

I'm happy to take a look at the .blend if you want.
http://games.joshkirklin.com/sulium

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
Chris Tate
DBPro Master
9
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 10th Mar 2018 14:59 Edited at: 10th Mar 2018 15:02
Thanks.

I am using Blender 2.78b, a year old; customized quite a bit

I'll PM the blend file. It is quite a mess because I am playing around with scripts and procedures. The offending mesh is called Body, and the armature is called Bones.
revenant chaos
Valued Member
11
Years of Service
User Offline
Joined: 21st Mar 2007
Location: Robbinsdale, MN
Posted: 10th Mar 2018 15:03
I've seen a few fpsc characters act like this before, but I didn't expect to see this behavior with your objects. I think this problem is caused by objects which use multiple frame matrices. The plugin doesn't support this feature (only one frame matrix, preferably identity), it could require bones to have multiple palette entries and would lead to hitting the 80 bone count limit much earlier. Until now I had only seen multi-mesh objects act this way, is it possible the head is now being exported as a separate mesh? With the example character you made for me I recall needing to recombine some of the meshes within fragmotion.
Chris Tate
DBPro Master
9
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 10th Mar 2018 15:23
Right; so I need to figure out what kind of operation could cause there to be more than one frame matrix. How do you detect how many frame matrices there are? Is there a keyword I can use to search the .X file?

Perhaps one of the blender modifiers are messing up the head and neck iteration order and producing the extra frame matrix; or perhaps I messed up the eyes. Something went wrong there. I am fully aware of the shoulder area needing lots of work, but it is only now that I see that the vertex order is going to be a serious problem.

So tomorrow I will try to inspect the vertices for any strays, and will play around with blender's vertex tools to see if I can fix the problem from there.

revenant chaos
Valued Member
11
Years of Service
User Offline
Joined: 21st Mar 2007
Location: Robbinsdale, MN
Posted: 10th Mar 2018 16:04
You could use IanM's DumpDBO tool to inspect the file (works with .x files as well). Each frame's "final" frame matrix can be calculated by concatenating the FRAME_MATRIX's with each of it's parent frames. The plugin calculates and uses the first mesh-frame's matrix for all of the object's meshes, this is what I wound up calling the permutation matrix because ideally frame matrices would amount to a mere identity matrix. Your exporter however relies on these frame matrices to perform corrections to the mesh/bone data at runtime rather than baking the coordinate-system conversion into the mesh/bone data itself. I mis-spoke when I referred to frame matrices in terms of quantity; The "final" frame matrices should be equal for all meshes-containing frames.
revenant chaos
Valued Member
11
Years of Service
User Offline
Joined: 21st Mar 2007
Location: Robbinsdale, MN
Posted: 10th Mar 2018 23:08
Hi everyone, here is yet another beta release which adds some new import tools and performance improvements.


Import Tool Updates:
===============================
- Added a "Mesh->Recalculate Normals" tool, uses DBPro's Set Object Normals command.
- Added a "Mesh->Recalculate Normals (Seamless)" tool for combating texture seams. Performs the calculations on a second copy of the object which is welded based on vertex position only. This tool is able to recover objects with faceted normals: After using this tool re-weld the vertices, then use this tool a second time.
- Added a "Mesh->D3D9 Vertex Cache Optimization" tool which runs the object's meshes through the ID3DXMesh:ptimizeInplace() method.

Bug Fixes:
-----------------------------------------------------
- When vertices which lack weight data are detected, error messages are now only triggered once per-mesh.


Plugin Updates:
===============================
- Implemented Animation LOD; decreases animation quality for distant objects. When enabled, displayed animation frames will be truncated to integer (avoids interpolating between frame transforms).
- Added JGS_SetCameraDistanceScale to allow greater control over per-camera LOD.

New Commands (3)
------------------------------------------------------
Count = JGS_GetDrawPrimitives( [CameraID] ) //Returns the number of primitives which were rendered during the last sync.
JGS_SetCameraDistanceScale CameraID, Scale# //Defines a multiplier which is used to modify animobject near-plane distances for greater control over the lod systems.
AnimObject_SetAnimationLOD pAnimObj, bEnabled [, Dist#] //Setup animation lod to be enabled at the specified distance.

Attachments

Login to view attachments
Chris Tate
DBPro Master
9
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 11th Mar 2018 01:38 Edited at: 11th Mar 2018 01:40
Thanks for the work; I will try out the new Beta once I rectify the problem I am facing. I will use that tool to inspect the model. From the look of things, somewhere along the way, the ordering got messed up in Blender; there might be a way to use a modifier to re-order the verts. Otherwise a programming or conversion solution will have to do.

Is that new near-plane camera distance also a way to reduce Z-fighting issues?

However narrowly supported, at some point in the next few weeks I am going to need to play around with Z bias to create special effects for maximal display options.

Looking foward to showing you the results; should be in about a 5-6 weeks from now if nothing goes wrong. If everything goes according to plan, I'm going to have to start donating towards this project, and some others.
Chris Tate
DBPro Master
9
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 11th Mar 2018 13:19
I'd like to ask a question. In the plugin functions, are frame parameters referencing ranges by a 0 based starting index, or 1 based starting index?

It appears that my animations look smoother when I increase the starting frames of each Blender frame-range by 1.

Come to think of it, I think I can spot the answer in the import tool. I exported frames 0 to 2200 from Blender; but the import tool indicates frames 0 to 2201. So I need to add 1 to each range in my game engine. Is that correct?
revenant chaos
Valued Member
11
Years of Service
User Offline
Joined: 21st Mar 2007
Location: Robbinsdale, MN
Posted: 11th Mar 2018 13:57 Edited at: 11th Mar 2018 14:01
Quote: "Is that new near-plane camera distance also a way to reduce Z-fighting issues? "

That command is used to offset the distances at which the LOD systems will take effect. Calling the command with a scale value of 0.5 will cause animobjects which are 100 units away to be treated as being only 50 units away, effectively doubling the distances at which LOD will kick in. Currently the only way to control AnimObject ZBias would be set the DepthBias effect state within your shaders.


Quote: "are frame parameters referencing ranges by a 0 based starting index, or 1 based starting index? ... So I need to add 1 to each range in my game engine. Is that correct? "

Animation frames are 1 based, so yes that is correct. Frame 0 refers to the bind pose.


[Edit] Could you try to run the original model with incorrect neck normals through the new import tool? I think using it to reweld and renormalize could fix the issue you were originally having.
Chris Tate
DBPro Master
9
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 12th Mar 2018 08:46 Edited at: 12th Mar 2018 08:47
Quote: "Currently the only way to control AnimObject ZBias would be set the DepthBias effect state within your shaders.
"


Ok thanks, I'll use the shader.

- One feature request for the import tool is for the textboxes to retain there values, or have an option to reuse the same paths when importing. I am always importing the same files. Would be a smashing feature and a real time saver.

Quote: "Could you try to run the original model with incorrect neck normals through the new import tool? I think using it to reweld and renormalize could fix the issue you were originally having."


Performing weld on the first export from Blender causes a crash. (It crashes whether or not it is unwelded in the import tool; which did not crash.)

During the crash this was the stack trace:


Address:


It also crashed with the Fragmotion import. and with the latest Beta version. This error report was from the previous one.



The normals look weird on recent character versions converted from Blender's direct X export script. Only the bypassing of normals exportation produces consistent results, except that there is no smoothing. I work around would be to be able to calculate the normals in Fragmotion, DBP or the import tool.

If I export using another format, such as .obj; the character looks almost identical in Fragmotion in comparison to Blender. The structure of the character does not get interpreted well by the script.

This problem was somehow introduced recently by one of my operations on the model, the first batch of characters did not cause any of such issues, only recently have I seen the problem. It is not in the model I supplied to you or my earlier models.

The problem is also occurring on the high poly export.


Here above is the model showcasing the issue after export. Shadows are where highlights should be. As if the normals are facing the wrong way.


Here above is the model in the test engine, without blender's export normals option. The highlights are on the correct side. I did not need to flip the normals on the X axis here. This is also the result of using the import tools Recalculate Normals feature.

The recalculate seamless feature causes the following crash:

Stack:


Address:


It seams like some vertex to vertex coding is going to be required my DBP engine, or I am going to have to tamper with the export script which is this:
revenant chaos
Valued Member
11
Years of Service
User Offline
Joined: 21st Mar 2007
Location: Robbinsdale, MN
Posted: 12th Mar 2018 19:10
Thanks for testing, It was worth a shot. The weld tool hasn't been touched since the last full release; Seeing as it doesn't crash with the old models you sent me (or any of the FPSC characters I use for testing), I am going to assume the crash also stems from your recent export problems. It makes sense that the seamless normals tool would crash, it relies on the weld function which also crashes. Unfortunately the language I'm using doesn't supply any tools which are useful for debugging dlls, typically I need to resort to the old-fashioned console logging method.
Chris Tate
DBPro Master
9
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 13th Mar 2018 09:15
No problem. I am always available for testing anything you need to have tested.

Fortunately the weld feature in Fragmotion fixes the problem; I can remove the invalid normals, then recalculate them there. So I will be able to complete the work.



Thanks for the help.

If you have any tips on chest breathing animations. I am all ears. I am going to try procedural breathing with sine waves with a bone assigned exclusively for breathing which does not mess up any deep bone hierarchies or scales of other bones.
Ortu
DBPro Master
10
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 14th Mar 2018 04:03
check your PM Chris.

for breathing I just scale up the chest bone by 1.1 and scale down the neck and shoulders by 0.9 which propagates down to the child bones in head and arms.
http://games.joshkirklin.com/sulium

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
Chris Tate
DBPro Master
9
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 14th Mar 2018 05:29
Thanks again for finding the cause of the problem. I have not tested your solution yet, but when I do I will show the result.

So I should try scaling the chest, while cancelling its impact on the arms and head using a negative value on the neck and shoulders. I will give it a go. I will do it with code so that the character behaviours can affect the breathing, and I do not need to create breathing keyframes for all the 100s of animations I will need.
Chris Tate
DBPro Master
9
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 14th Mar 2018 06:04
It looks like adjusting and applying the armature requires a clean up of all animations and bones. Not as straight forward as it at first seamed. I will have to come back to this problem later, after completing urgent work on the engine.
Chris Tate
DBPro Master
9
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 14th Mar 2018 13:21
Do not ask me how, but some how, the problem went away; even without performing any origin changes, or any of the proposed solutions.

After the creation of some new animations, the invalid normals problem ceases to occur. Oh well, back on topic now.
Ortu
DBPro Master
10
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 14th Mar 2018 15:01
Always an adventure!
http://games.joshkirklin.com/sulium

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
Chris Tate
DBPro Master
9
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 14th Mar 2018 16:41
Lol

So RC; how does the startframe parameter get utilized by playback ranges? I am working on fighting stances; let's say for example that the stance is defined at frame 100, and the animation range is from 110 to 120. Prior to playing the specified range, will the plugin interpolate the transforms from frame 100 into the transforms of frame 110 for the specified duration; or will it play all frames from 100,101,102 to 110 for the specified duration?
revenant chaos
Valued Member
11
Years of Service
User Offline
Joined: 21st Mar 2007
Location: Robbinsdale, MN
Posted: 14th Mar 2018 17:43 Edited at: 14th Mar 2018 17:49
The Loop commands' startframe parameter is used to specify the "entry frame" into an animation loop, rather than being forced to begin at the loop's firstframe. If you have an animation ranging from 10 to 20, you could use a startframe of 15 to begin the loop halfway through. The startframe should be >=firstframe, and <=lastframe; a value of 0 is treated as if startframe=firstframe.

In the examples you may have noticed the firstframe and lastframe parameters are both set to 0, in this case the animobject will loop through the entire animtrack.



[Edit] Oops missed this one.
Quote: "One feature request for the import tool is for the textboxes to retain there values, or have an option to reuse the same paths when importing."
Hmm, on my computer the openfile dialog retains the path from the last imported object (even between executions). Could you try running the tool as an administrator?
Chris Tate
DBPro Master
9
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 14th Mar 2018 20:27
Thanks for the tip. So the start frame is relative and limited to the range; except for zero which means the start frame.

It seems that I will need to use the BlendTo/TransitionTo commands for jumping from one animation to another animation, by association.

In other words, in game coding terms, I want to set the frame to a fighting stance, then blend to the attack, then ease back to the fighting stance; where the are multiple optional or random attack animations for each fighting stance, I can switch between them using the easing functions.

Quote: "[Causes a secondary animation to begin looping onto an AnimObject's skeleton. The plugin will then ease into the new animation over the specified amount of time, after which it will become the AnimObject's primary animation."




I ran the tool as administrator; all textboxes are empty upon import/save after every use.

It does remember my working directory however.


Chris Tate
DBPro Master
9
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 16th Mar 2018 10:38 Edited at: 16th Mar 2018 10:39
Interestingly, non looped playback calls ended up playing beyond the specified range specified by AnimObject_Play and AnimObject_TransitionTo. Is this a bug?

Quote: "LastFrame FLOAT The ID of the destination frame"


The LastFrame parameter should be the final destination frame of the animation, so it shouldn't keep playing frames 11 onward if the range is 1 to 10 for instance.

Note that it sometimes crashes the application after about 20 seconds or so; only when ever Play instead of Loop is used.

Latest Beta version.
revenant chaos
Valued Member
11
Years of Service
User Offline
Joined: 21st Mar 2007
Location: Robbinsdale, MN
Posted: 17th Mar 2018 06:24
Yeah, that definitely shouldn't be happening. I had a quick look into this before posting, but was unable to reproduce the symptoms you describe. I'm hoping to take a better look into this tomorrow, could you post a simple example which demonstrates the error?
Chris Tate
DBPro Master
9
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 17th Mar 2018 06:48
I could not reproduce the problem in a separate project, so the cause of the problem must be in my main project. Since this is the case, I have a feeling the database data used to define animations is causing the model to play a frame range out of range, which could be the cause of the crash. I think if look into the parsing code I might find the route cause.

In the meantime, do you know what I can do to prevent z fighting issues from clipping entire polygons intersecting other polys. It is demonstrated in the video linked here: http://www.sportsfictiongame.com/sf/problems/jgpu-zfighting.mp4



My near camera range is 2mm. - 0.02 units.
revenant chaos
Valued Member
11
Years of Service
User Offline
Joined: 21st Mar 2007
Location: Robbinsdale, MN
Posted: 18th Mar 2018 05:49
Seems your server is down at the moment so I can't see the pic or video. Unfortunately D3D9 doesn't offer much in the way of reliably correcting z-fighting, but I would try increasing the camera's near range a bit if possible. You might also be able to get some results by playing around with the ZFunc effect state.
Chris Tate
DBPro Master
9
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 18th Mar 2018 16:52
Server rebooted.

I will look into what I can do with ZFunc.
revenant chaos
Valued Member
11
Years of Service
User Offline
Joined: 21st Mar 2007
Location: Robbinsdale, MN
Posted: 19th Mar 2018 01:27
Is the character standing on a very low-poly object, such as a plane? If yes, these precision problems might be alleviated by increasing the ground object's polycount.
Chris Tate
DBPro Master
9
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 19th Mar 2018 15:15
Yes, the ground is low poly.

I will test it with higher poly geometry after making some preparations.
Chris Tate
DBPro Master
9
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 28th Mar 2018 05:46
I hope all is well

How do you think I should implement character editing with jGPU skin? Do you think I should alter the vertex data to change the look of the source mesh, or avoid altering vertex data where possible and attempt to load separate purpose built meshes for each of the players? Or should I perhaps write a solution in a vertex shader function?

I have a number of solutions in mind, I am not sure which is best for jGPU skin conformity.
revenant chaos
Valued Member
11
Years of Service
User Offline
Joined: 21st Mar 2007
Location: Robbinsdale, MN
Posted: 29th Mar 2018 17:34
Hi Chris,
The plugin supports all of the aforementioned solutions, but it is tough to say which is best without case-specific testing on your target hardware.

It is often said that drawcalls are our biggest enemy with d3d9, but the truth is that changing the renderstate is the real performance killer. Other than memory usage, those state changes are the real difference between dbp's clones and instances; instances can be rendered with minimal changes to the renderstate while clones can not (even if the clones are identical).

Rendering many unique objects requires many changes to the renderstate (vertex/index buffers, effects, textures, etc), this will be true weather you directly load the meshes or produce each variation with code. Seeing as any animobjects which use unique geometry will require unique dbp objects either way, I don't think there will be any difference in terms of performance.

Editing vertexdata in real time is possible but may become an issue when combined with mesh lod; Updating multiple meshes within a single frame will likely cause unacceptable stalls in the graphics pipeline. On the other hand, editing vertexdata grants access to normals and blend weights.

Vertex shader based approaches can allow updates to immediately become visible across all LOD levels, but may not be viable on lower end graphics hardware if the implementation requires texture lookups.

If VS3's texture lookups turn out to be fast enough, the plugin has an undocumented feature which may be useful; Texture references are collected when the dbp object is assigned to the animobject. If you change the object's texture inbetween assigning it to various animobjects, you can trick animobjects into sharing a common object while still rendering each with unique textures.
Chris Tate
DBPro Master
9
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 29th Mar 2018 20:21 Edited at: 29th Mar 2018 20:26
Understood. I think I will start from the easiest solution which requires identical objects.

According to your suggestion, it seems that the fewer sources-objects, the more likely for the system to perform well; which also means the less work required in the editor because I'd be dealing with a couple objects. I think I will start off with one male and one female model cloned with a counterpart dedicated face and skeleton as an additional object bound to the neck bone. The LOD system can omit this complication when the character is distant. This is perhaps the easiest coding and 3D modelling solution since I'd only need to create a few models with an extra skeleton; the code requirement would be a trivial case of offsetting the bones in the face skeleton, I could scale and rotate them if they have no child bones. Being a separate skeleton, I'd have plenty of bones available to define the face.

Even if 20 or 30 characters would still require separate objects due to texturing and shading differences, at the very least there are no complex vertex calculations required to be added, not more than a single iteration to apply offsets, and the face skeleton would only be required when close to the camera.

The body can be personalized with texturing and costumes.

Texture lookups, vertex texcoordinates, colors, psize and other paramaters could be a fallback option for vertex shading should the bone method fail.

I could easily export lots of meshes with different faces from Blender, and have them interpolated by the UI sliders in an editor, but I always try to steer away from using the CPU where the GPU/s could perform the same task without any issues, especially with the command-set available in jGPU skin.

I think I will also store all generic clothing in the same object, to reduce the amount of object loading.
Chris Tate
DBPro Master
9
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 8th Apr 2018 09:19
Hi, how are things?

All was working well until I attempted to add a fog and depth of field functions to the skin .fx files, unfortunately this broke the runtime execution with the following warning message:

Quote: "
---- Warning ----
error X1507: failed to open source file: 'C:\Users\MainUser\AppData\Local\Temp\dbpdata43\jGpuSkin_Include.fxi'
"


Here is my copy of the skin shader; it was altered to include fog and depth calculations, and was successfully compiled with FXC:



It appears that the .fxi is being written in my shader folder, but the compiler is looking for the file in another; all of a sudden. Perhaps I using an old version of your shader and will need to update it?
revenant chaos
Valued Member
11
Years of Service
User Offline
Joined: 21st Mar 2007
Location: Robbinsdale, MN
Posted: 8th Apr 2018 23:22
Hi Chris,
I've been good thanks, and you? I don't recognize that error message, seems dbpro is triggering it. Does the error occur when loading the ascii .fx file? I haven't used fxc in years but I suspect include files don't work well with precompiled shaders, at least not in the way the examples use them. During early stages of the plugin's development, I discovered that the size of shader arrays had a considerable impact on rendering performance. The include file was implemented as a quick and easy way of changing shader array sizes to custom-fit each animobject's palette requirements, but I suspect this method will not work with precompiled shaders.

Could you try removing dependency on the include file? That can be done by applying the following changes to the shader:


With these changes you will no longer need to call SetSkinFxHeader() before loading the effect, but the animobject will not benefit from having a custom-fit shader array for it's bone palette. It is not required that array sizes exactly match the animobject's required palette size, as long as there is at least 3 array indices per weighted bone. I haven't tested this, but the ability to share effects across multiple animobjects may have reduced the importance of custom-fitting shader arrays to each animobject. For example: Lets say one character has 80 weighted bones and another has 78. Rather than changing the render state's effect, it could possibly be faster for the two animobjects to share a single effect which is equipped to handle 80 bones. If a character uses far less than 80 bones, it may once again become worth it to apply a shader with a smaller palette array.
Chris Tate
DBPro Master
9
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 9th Apr 2018 04:20
I am using ASCII shader files. I use FXC for debugging, although I have experienced considerably faster loading times with compiled FX shaders, it is more convenient for me to not have to keep batch compiling, while tweaking the engine.

I think DBPro is exporting all plugin DLLs into the temp folder. For some reason, after editing the shader, your plugin is looking for the FXI in the temp folder and not the designated shader directory. I was thinking it has something to do with one of my own DLLs affecting the current directory of your DLL, having set the current directory to the shader directory and bypassing the use of my DLL, I still cannot fix the problem.

Thanks for the tips, I will hard code the palette size for now.

Chris Tate
DBPro Master
9
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 9th Apr 2018 04:37 Edited at: 9th Apr 2018 04:38
OK, I have just performed another test, simply because the occurrence bothered me.

After hard coding the palette sized, the error message changed to something else. The error message returned by Perform Checklist For Effect Errors was not revealing the main problem, which was missing definition in my tweaked code.

When I added the missing definition, it no longer displays any error message. Perhap's that include problem is a warning and not an error; I am guessing that it ends up finding the FXI after trying the temp DLL folder; otherwise the system would have never have worked. The PCFEE command has never been very reliable, maybe a potential feature request in the future would be for a better error report; for now it may suffice to use FXC.

I have re-included the FXI file and the dynamic palette size which works again.

Login to post a reply

Server time is: 2018-06-24 21:25:39
Your offset time is: 2018-06-24 21:25:39