Request for custom model

[SteveL]

Done and here is a small taster vid for your enjoyment -

 

https://www.youtube.com/watch?v=DaU0bi_OI2A

Thanks for making the bottom non-frobable

Edited September 1, 2015 by SteveL

[Arcturus]

Would it be possible to change door / lid animation's curve from linear interpolation to more natural bezier curve? Here at 17:50 it's explained why it's important: http://www.gdcvault.com/play/1020583/Animation-Bootcamp-An-Indie-Approach

[SteveL]

Would it be possible to change door / lid animation's curve from linear interpolation to more natural bezier curve? Here at 17:50 it's explained why it's important: http://www.gdcvault.com/play/1020583/Animation-Bootcamp-An-Indie-Approach

I don't understand... the hinge position is static for your ottoman, so you want the lid to pivot about a stationary axis (which is what it does). It's not like that gun where you have both translation and rotation happening at the same time.

[Arcturus]

Here's an example:

 

[Bikerdude]

I still dont understand that kind of movement your aiming for as the video amove just shows opening and closing like I have it in the prefab.

 

But if a real ottman has a double hinge, then Im sure we could work that into the prefab.

[Arcturus]

I guess it's subtle. Currently the speed of rotation is constant, which is robotic and unnatural. Normally human movement, e.g. that of hand opening something accelerates at the beginning and slows down just before end. For example automatic head turning of NPCs follows that rule (although I would tweak it if I could). Right now lid starts at constant speed and then stops immediately. My example shows curve of that rotation - first how it looks now and then how I would see it.

[Bikerdude]

Ah I see what you mean, I imagine it would either have to be scripted or coded to obtain the desired effect.

[grayman]

Movers (for example, an elevator) include code for acceleration and deceleration.

 

Doors (and lids are doors) do not.

 

I'm guessing that it was designed this way because doors spend very little time moving, and travel short distances. Things like an elevator are big and heavy and spend a lot of time getting to where they need to be and travel longer distances. So in the case of movers, a bit of acceleration and deceleration will be noticed, especially if there are sounds associated with acceleration and deceleration. Acceleration and deceleration on doors won't be noticed.

 

While it would be nice to model the real world in all instances, we have hundreds of problems that need addressing (and very few coders), and after 7 years, it doesn't seem worthwhile to add a MESS of code to door movement to simulate something that most people just aren't going to notice. All the code that touches door movement assumes a linear translation (of time and/or distance and/or angle), and so it's more than just changing the door code.

 

Mappers, of course, are free to create custom doors (and lids) that aren't doors, but movers (I've done this myself), which gives them access to acceleration and deceleration.

 

My two cents.

[Epifire]

Done and here is a small taster vid for your enjoyment -

 

https://www.youtube.com/watch?v=DaU0bi_OI2A

 

Makin me really giddy when lookin at dis. Also liking the soundscape on a side note. Only thing that stuck out to me when I saw the video was that I must have set noselfshadows on the chair's material (since the moonlight was casting through the back). That reminds me I still need to figure out what's up with my custom collision/shadow meshes when I finalize the exports with Blender. Someday I may be able to give you the optimized version. One that also allows the other ottoman to be moved around as a phys object.

 

Would it be possible to change door / lid animation's curve from linear interpolation to more natural bezier curve? Here at 17:50 it's explained why it's important: http://www.gdcvault.com/play/1020583/Animation-Bootcamp-An-Indie-Approach

 

Yeah honestly if this were done on pretty much all hinged doors that would be fantastic. No prior knowledge on animations within id4 myself, but I know ease in/ease out really helps the believable factor 10x.

Edited September 1, 2015 by Epifire

[Arcturus]

@grayman
I understand that there are not enough coders. However I don't agree that no one would notice. Even if only subconsciously. Details matter. Doom 3 had indeed very fast doors, but they were also sliding. I don't recall any rotating doors in D3, hence the code. In Darkmod doors are rather slow. Also it's not about modelling real world but rather about aesthetics and what 'feels' right rather then what 'is' right.

 

Yeah honestly if this were done on pretty much all hinged doors that would be fantastic. No prior knowledge on animations within id4 myself, but I know ease in/ease out really helps the believable factor 10x.

I agree.

[grayman]

Well, after actually looking at the code, I have to retract what I said above about doors not supporting acceleration/deceleration.

 

Set these values on the door:

 

accel_time N (seconds, default is zero)

decel_time M (seconds, default is zero)

 

By default, doors take 1.75 sec (move_time) to fully open, so make sure your accel and decel times are appropriate.

 

Accel and decel are linear.

 

Sorry about the confusion. It always helps to take your meds before opening your mouth!

[Epifire]

Sorry about the confusion. It always helps to take your meds before opening your mouth!

 

Or open your mouth before taking your meds.

 

I don't mean to detract from the conversation but I couldn't resist that

[Springheel]

Set these values on the door:

 

accel_time N (seconds, default is zero)

decel_time M (seconds, default is zero)

 

By default, doors take 1.75 sec (move_time) to fully open, so make sure your accel and decel times are appropriate.

 

 

Would these values have any impact on things like AI noticing doors or sounds being reduced? Are those things coded by degrees or by time?

[grayman]

Both are tested against % open (rotational degrees or sliding translation), so:

 

1 - An opening door with acceleration would take longer for an AI to notice it (at 20% open).

 

2 - An opening door with acceleration would take longer to reach no sound occlusion (at 50% open).

 

3 - A closing door with acceleration would take longer to start occluding sound (occlusion starts ramping up at 50% closed).

 

4 - A closing door with deceleration would take longer to reach full sound occlusion.

[Springheel]

That sounds right to me. Those things are based on how much the door is open, not how long it takes to open, so improving the visuals with acceleration and deceleration wouldn't affect those things unrealistically. Might have an undesirable effect on doorsounds, though we're probably talking milliseconds.

[Arcturus]

Great. I added

accel_time 0.15
decel_time 0.6

to the ottoman prefab. Move_time is set to 0.75. Sum of accel and decel can be lower than move_time by the way.

 

 

This is a door with move_time 1.75 and

accel_time 0.7
decel_time 0.7

[Springheel]

It's subtle, but it does look more natural.

[Arcturus]

I reduced polycount of the ottoman. I added one lod stage for lid and body and updated prefab to use them. Also added skins:

 

[Bikerdude]

Grr gonna have to make some purple skins for the other coloured furniture now mister

[Arcturus]

Not going to happen, I'm afraid.

[Bikerdude]

Not going to happen, I'm afraid.

Sorry I meant to say I will have to make some purple skins, Ive already made green and blue, so it will be very simple to tweak the existing skins :-)

 

Whats the exact shade of purple you used..?

[Epifire]

Great. I added

accel_time 0.15
decel_time 0.6

to the ottoman prefab. Move_time is set to 0.75. Sum of accel and decel can be lower than move_time by the way.

 

 

This is a door with move_time 1.75 and

accel_time 0.7
decel_time 0.7

 

Looks great. Makes the motions feel blended. Only thing the wood door was missing was that slight return you had in the animated mover version (on the door_open sequence). Though for obvious reasons, I can understand why the entity based version wouldn't handle that. Will be keeping this in mind though for when I'm actually able to get to work on my own FM. It really is the little things that add a whole new level of polish.

Edited September 4, 2015 by Epifire

[Arcturus]

I had to crank up colours on those additional skins because everything in Darkmod is very saturated.

[Arcturus]

Whats the exact shade of purple you used..?

That will be #794b71

[Bikerdude]

Done.