:: Home :: Get Hosted :: PPM FAQ :: Forum FAQ :: Search :: Memberlist :: Usergroups :: Register :: Profile :: Log in to check your private messages :: Log in ::
Do you want to advertise at Project Perfect Mod. Find out how to do it HERE.

The time now is Tue Nov 21, 2017 8:24 am
All times are UTC + 0
 Forum index » Modding Central » OpenRA Editing Forums
OpenRA Blog
Moderators: Global Moderators, OpenRA Moderators
Post new topic   Reply to topic Page 4 of 4 [176 Posts] View previous topic :: View next topic
Goto page: Previous 1, 2, 3, 4
Author Message
pchote
Cyborg Soldier


Joined: 06 Feb 2015

PostPosted: Sat Jul 02, 2016 8:40 am    Post subject: Reply with quote

This is a simple and isolated interpolation problem.  The code for moving units through cells lerps the position and facing between their initial and final values on entering/leaving the cell.  This is wrong, and gives the behaviour we see where the unit slides in a different direction to its facing.

The fix is to make UpdateCenterLocation use a higher order interpolation that curves through the cell and sets the facing to the tangent of the path.  I imagine that the original games used a look up table, but we could do it more easily using splines.

Back to top
View user's profile Send private message
OmegaBolt
President


Joined: 21 Mar 2005
Location: York, England

PostPosted: Sat Jul 02, 2016 8:46 am    Post subject: Reply with quote

Iran wrote:
The vehicle turning logic and movement is a bit off, the turning especially looks weird. The turning is really, really smooth.
I agree however this is customisable in the mod. You can set the number of visual facings are taken from the voxel.
_________________
TAK02 wrote:
Screw AttachEffect. Can't think of any use for it.

Back to top
View user's profile Send private message Send e-mail MSN Messenger
Iran
Cyborg Specialist


Joined: 23 Mar 2011

PostPosted: Sat Jul 02, 2016 11:38 am    Post subject: Reply with quote

Ah, does it look better than?

Other than that both Tiberian Sun and RA2 look a lot better under OpenRA. Maybe it's time to add OpenRA support to CnCNet.

Back to top
View user's profile Send private message
G-E
General


Joined: 09 Feb 2015

PostPosted: Sat Jul 02, 2016 10:55 pm    Post subject: Reply with quote

I don't see why some facing increment isn't updated in parallel to the rendering, afterall if it can display the facing, it should be aware of the facing no?

Many of the movement issues between cells would be fixed if the ROT was linked to speed, and the direction of travel was linked to ROT (facing) wouldn't they? I don't see any spline calculations being necessary, that presupposes knowing the entire trajectory regardless of acceleration or other factors, which seems like the wrong approach.

I'd argue the WW engine actually does a little preplanning for aircraft, and doesn't take into account facing at a granular level which causes aircraft in some cases (when the engine is busy or the aircraft is too fast) to turn backwards instead of a banking forward turn. If the movement was always relative to the previous movement, any lag would just make the turning more jerky as precision is lost, nothing major.
_________________
http://www.moddb.com/mods/scorched-earth-ra2-mod-with-smart-ai

Back to top
View user's profile Send private message
Matthias M.
Jumpjet Infantry


Joined: 15 Jun 2012
Location: Germany

PostPosted: Sun Jul 03, 2016 7:48 am    Post subject: Reply with quote

Iran wrote:
Maybe it's time to add OpenRA support to CnCNet.


That might be easy from a technical standpoint. Our "global chat" also uses IRC and joining servers works with openra:// links. Loading the server list is a matter of parsing a .yaml or .json file. http://www.openra.net/games/

Back to top
View user's profile Send private message Visit poster's website
pchote
Cyborg Soldier


Joined: 06 Feb 2015

PostPosted: Sun Aug 07, 2016 6:51 pm    Post subject: Reply with quote

#11788 should fix the worst of the smooth movement complaints in the next release.

Back to top
View user's profile Send private message
pchote
Cyborg Soldier


Joined: 06 Feb 2015

PostPosted: Tue Aug 23, 2016 7:27 pm    Post subject: Reply with quote

The per-pixel depth calculations that I showed off back on page 3 of this thread (nearly a year ago now) are finally finished, and i'm going to strongly enourage our other devs to get the final PRs reviewed and merged before our next release.

While it may not seem like a big deal if you don't understand how our rendering works, this was actually our single biggest blocker for releasing the gen2 (isometric/heightmapped) mods.  There's still a lot more work to go around the edges, but our fundamental engine design now finally supports proper isometric rendering.  Like you might expect, we've gone further than TS's limited global buildngz.shp and support per-sequence depth data: this means that you can have pixel-perfect intersections, just like real 3d models, if you configure your artwork pipeline to render out depth sprites along with your normal shps.

The most obvious results are that units/weapons/etc now disappear behind cliffs, and don't disappear behind flat things like gates or building bibs.


Back to top
View user's profile Send private message
Lin Kuei Ominae
Seth


Joined: 16 Aug 2006
Location: Germany

PostPosted: Tue Aug 23, 2016 8:07 pm    Post subject: Reply with quote

Rating 10 out of 10! Perfect! of  Rating 10 out of 10! Perfect!
Applauses!  Approved!


I never checked out buildngz.shp. Can you describe shortly where this is used and how it works? So far, i only used the ZAdjust keys to hide objects behind the building or ActiveAnim.

Do you plan to incorporate such height infos into projectile hit calculations? Allowing high flying projectiles to fly over low building parts and hit high building parts.
_________________
SHP Artist of Twisted Insurrection. Main Nod building SHP creator.

Public SHPs
X-Mech Calendar (28 Mechs for GDI and Nod)
5 GDI, 5 Nod, 1 Mutant unit, 1 Scrin unit, 1 GDI building

Tools
TMP Shop
C&C Executable Modifier

Back to top
View user's profile Send private message
Banshee
Supreme Banshee


Joined: 15 Aug 2002
Location: Brazil

PostPosted: Tue Aug 23, 2016 9:52 pm    Post subject: Reply with quote

Congratulations guys. I'm a bit silent in this topic, but I'm watching it and I'm very interested in the results posted here Smile.

Back to top
View user's profile Send private message Visit poster's website MSN Messenger
pchote
Cyborg Soldier


Joined: 06 Feb 2015

PostPosted: Tue Aug 23, 2016 9:59 pm    Post subject: Reply with quote

Basically it defines a per-pixel z-offset that is applied to buildings so that the "x is in front of y" lines run diagonally, parallel to the cell edges, instead of horizontally across the sprite.

Why is this needed? Consider a building is that is much longer than it is wide, like the gate (lets call it G) in the screenshot above.  An actor A that is to the NW of the bottom cell should obviously be rendered behind the gate (A < G), and an actor B that is to the SE of the top cell should obviously be drawn in front of the gate (G < B).  But this is logically impossible if you use the simple rule for "things closer to the bottom of the screen are drawn in front" (which is the best you can do if you have flat sprites with no extra info), because B < A but A < G < B implies B > A.  If you render the world as a bunch of flat planes then you are forced to draw one actor behind another that it should visually appear in front of.  This produces bugs like ra2#147 - notice that the tesla trooper is indeed "behind" the center of the telsa reactor's footprint.

The original TS has hardcoded rules for aligning the pixel offsets stored in buildngz.shp to the footprint (this will be one of the reasons why TS/RA2 didn't let you define arbitrary footprints) and other hardcoded rules for things like bib sprites that don't use it.  I've set it up in OpenRA so that everything can be defined per-sequence, so you can use depth maps that correspond to the actual sprite instead of just a generic rectangular box.

There's no plans to let these affect projectile hit calculations (we have a hard rule that gameplay simulation state can't depend on artwork or render state), but our collision logic is already much more flexible than the original games.  It wouldn't be a huge effort to define a rough 3d collision shape (made out of boxes or spheres) in mod code that does the same thing.

Back to top
View user's profile Send private message
Lin Kuei Ominae
Seth


Joined: 16 Aug 2006
Location: Germany

PostPosted: Tue Aug 23, 2016 10:24 pm    Post subject: Reply with quote

thanks for the explanation.
Crazy what kind of techniques were implemented by WW to get the isometric view work.
pchote wrote:
because B < A but A < G < B implies B > A.

i like such pure and simple logic. Smile
_________________
SHP Artist of Twisted Insurrection. Main Nod building SHP creator.

Public SHPs
X-Mech Calendar (28 Mechs for GDI and Nod)
5 GDI, 5 Nod, 1 Mutant unit, 1 Scrin unit, 1 GDI building

Tools
TMP Shop
C&C Executable Modifier

Back to top
View user's profile Send private message
pchote
Cyborg Soldier


Joined: 06 Feb 2015

PostPosted: Sat Aug 27, 2016 9:15 pm    Post subject: Reply with quote

Working on these features sometimes gives some fun insights into the original game's development process.

A side-effect of the depth-correct rendering is that the near-ground-level laser turret beams clip through walls in a rather ugly way



So, how did WW avoid this?  They cheat, of course!



Notice that the central core of the beam clips through the wall in almost exactly the same way.  They then hide this by rendering a second (wider, more translucent) beam over the top with a large enough positive Z-offset to cover up the clipping.
We can measure the z-offset between the 'real' and 'z-fudged' beams by shooting through a larger structure and counting the pixel offset between the two cutoff points



This works out as 12px, or half a cell, which makes sense.

At some point I'll add the option to render the second z-fudged beam to our OpenRA lasers so that we can emulate this behaviour.

Back to top
View user's profile Send private message
Lin Kuei Ominae
Seth


Joined: 16 Aug 2006
Location: Germany

PostPosted: Sat Aug 27, 2016 10:59 pm    Post subject: Reply with quote

the main beam should also get a z-fudge fix.
No reason to repeat WW mistakes or bad solutions.

It might be also nice if such a laser beam can be blocked by walls (though only if a certain key is set, like AffectedByWalls: true).


Would the current system respect the lasers start and end point height and render it correct above walls if for example the start point on the turret is 48 pixel higher?
In other words, does the laser effect have only 1 z-value for the entire line or different z-values along the line?


Is the main laser lines thickness adjustable via the weapons yaml? Could be a bit thinner to look more like TS
_________________
SHP Artist of Twisted Insurrection. Main Nod building SHP creator.

Public SHPs
X-Mech Calendar (28 Mechs for GDI and Nod)
5 GDI, 5 Nod, 1 Mutant unit, 1 Scrin unit, 1 GDI building

Tools
TMP Shop
C&C Executable Modifier

Back to top
View user's profile Send private message
pchote
Cyborg Soldier


Joined: 06 Feb 2015

PostPosted: Sun Aug 28, 2016 12:46 pm    Post subject: Reply with quote

The z-fudge isn't a fix, doing it to the main beam would just move the rendering glitches to other cases (e.g. low-flying aircraft going over the turret but under the beam).  The z-values vary along the line.

Blocking height and classes are already completely customizable... some discussion of that happened back on page 3.

Back to top
View user's profile Send private message
Matthias M.
Jumpjet Infantry


Joined: 15 Jun 2012
Location: Germany

PostPosted: Mon Aug 29, 2016 5:55 am    Post subject: Reply with quote

Lin Kuei Ominae wrote:
Is the main laser lines thickness adjustable via the weapons yaml?


Yes, it can be adjusted.

Weapon definition documentation is also coming soon: https://github.com/OpenRA/OpenRA/pull/11913

Back to top
View user's profile Send private message Visit poster's website
pchote
Cyborg Soldier


Joined: 06 Feb 2015

PostPosted: Fri Nov 18, 2016 8:55 am    Post subject: Reply with quote

Work on TS is still ticking along slowly:
  • #12370 implements cliff visibility blocking.
  • #12371 implements low-bridge damage, demolition, and repairing.
  • reaperrr has done a great job finding and fixing z-sorting bugs in the sequence definitions plus other polish fixes (too many prs to list).



Back to top
View user's profile Send private message
Crimsonum
Seth


Joined: 14 Jul 2005
Location: Fineland

PostPosted: Fri Nov 18, 2016 9:24 am    Post subject: Reply with quote

Very nice, looks almost identical to how TS did it, but smoother.
_________________

Twisted Insurrection co-leader

Back to top
View user's profile Send private message Visit poster's website
SMIFFGIG
General


Joined: 03 Mar 2003
Location: Great Britain

PostPosted: Fri Nov 18, 2016 11:54 am    Post subject: Reply with quote

Amazing, I love what you guys are doing!

Just curious, will units on higher cells have increased visibility over the lower cells (e.g. Unit on cliff).

If I remember correctly this logic was (at least to some extent) existent in TS but unused.
_________________

Back to top
View user's profile Send private message Send e-mail MSN Messenger
Lin Kuei Ominae
Seth


Joined: 16 Aug 2006
Location: Germany

PostPosted: Fri Nov 18, 2016 2:07 pm    Post subject: Reply with quote

any progress is good progress, no matter how slow it is. Smile

Higher object postion towards lower target providing bigger sight and weapon range would be indeed a very nice feature.

TS has this implemented in a broken way (LeptonsPerSightIncrease / LeptonsPerFireIncrease), why it was never enabled (keys using very high values in rules.ini).
Because here it was an absolute factor. Every map height level giving a unit a certain bonus to sight and weapon range, regardless of the targets height position.
So if a flat map was entirely on height 12, all units would have a higher sight/range than on a flat map that is on height 0.
_________________
SHP Artist of Twisted Insurrection. Main Nod building SHP creator.

Public SHPs
X-Mech Calendar (28 Mechs for GDI and Nod)
5 GDI, 5 Nod, 1 Mutant unit, 1 Scrin unit, 1 GDI building

Tools
TMP Shop
C&C Executable Modifier

Last edited by Lin Kuei Ominae on Fri Nov 18, 2016 2:11 pm; edited 1 time in total

Back to top
View user's profile Send private message
Crimsonum
Seth


Joined: 14 Jul 2005
Location: Fineland

PostPosted: Fri Nov 18, 2016 2:10 pm    Post subject: Reply with quote

The logic exists in TS, but it's not very well implemented. IIRC, units on high ground have overall longer sight and weapon range than units on lower ground. Obviously a more realistic way would be to have the range increase only in relation to lower ground (i.e. when the unit is standing near the edge of a cliff/slope).

EDIT: LKO beat me to it. AFAIK the logic was enabled in TS, at least LeptonsPerSightIncrease and LeptonsPerFireIncrease had achievable values (2000 leptons for both, meaning approximately 8 height levels).

I also remember testing it and IIRC I found that artilery on map Height level 4 could fire a cell farther than artillery on Height 0, and on Height 8 they could fire two cells farther than Height 0, respectively. The range increase could've been explained by the ballistic nature of their projectile, though, as the target was located at Height 0 in all cases.
_________________

Twisted Insurrection co-leader

Back to top
View user's profile Send private message Visit poster's website
Graion Dilach
Defense Minister


Joined: 22 Nov 2010
Location: Iszkaszentgyörgy, Hungary

PostPosted: Fri Nov 18, 2016 3:17 pm    Post subject: Reply with quote

What OpenRA got is basically a hard-check against a defined-on-the-sight-trait value, heightlevels above that value stay unrevealed. This defaults to -1 (>0 values mean disabled) and is set to 3 on the screenshot.
_________________



AS Discord server: https://discord.gg/7aM7Hm2

Back to top
View user's profile Send private message MSN Messenger
pchote
Cyborg Soldier


Joined: 06 Feb 2015

PostPosted: Fri Nov 18, 2016 5:08 pm    Post subject: Reply with quote

Like Graion said, this currently only supports a cutoff for cells above the actor.  It would be easy to add height bonuses if someone defined a set of parameters and filter criteria that maps a height delta to a sight range.  I won't be doing that myself though.

Back to top
View user's profile Send private message
pchote
Cyborg Soldier


Joined: 06 Feb 2015

PostPosted: Sat Nov 26, 2016 10:06 pm    Post subject: Reply with quote

Some more progress towards TS-style terrain: #12371 and #12430 implement ground-level bridges, and #12431 fixes the issue where units travel too far behind cliffs.

#12396 fixes the graphical glitches with carryalls and deployer units, and is just a small part of the upgrades system overhaul that will make it much more powerful and modder friendly.

Back to top
View user's profile Send private message
pchote
Cyborg Soldier


Joined: 06 Feb 2015

PostPosted: Sun Jan 15, 2017 2:22 pm    Post subject: Reply with quote

We have some more great TS progress in the review queue with #12571 implementing the bouncing disc logic, #12557 emulating the classic reveal-on-fire logic, and #12577 adding subterranean and jumpjet units plus tunnels and (indestructable but usable placeholders for) elevated bridges.

Back to top
View user's profile Send private message
kainzal
Guest




PostPosted: Tue Mar 21, 2017 9:38 pm    Post subject: Reply with quote

it would be great if you added the explosion-effects of buildings and vehicles of Tiberian Sun Dusk .. ..they look really great.. ..look: .. https://vimeo.com/1156606 ..greetings..

Back to top
pchote
Cyborg Soldier


Joined: 06 Feb 2015

PostPosted: Sun May 07, 2017 10:03 pm    Post subject: Reply with quote

It's been a while since anybody has posted here, so here's an update on what we've been working on for TS:
  • I implemented Laser fences (#13025).
  • reaperrr implemented tiberium floaters (#13174).
  • MustaphaTR set up the tech level options (#12984).
  • MustaphaTR polished the order of our sidebar cameos (#13053).
  • reaperrr worked on a bunch of balance and gameplay fixes (#12921, #12606, #13164).
  • Me and (mainly) reaperrr worked on a bunch more graphical fixes (#12993, #13048, #13080, #13210).
  • Me and reaperrr fixed most of the remaining issues with Jumpjets, subterranean units, and tunnels (#12924, #13149, #13159, #13160, #13162, #13217).  These now feel well integrated with the game.
  • atlimit8 has been working on replacing the remaining uses of actor-level disabling with trait-level conditions (#12955, #12996), which will fix several issues with the EMP cannon and stealth generators.
  • reaperrr has been working on Juggernauts (#13041), which has been easier said than done.
  • I finally got around to fixing our unintuitive range parsing in the isometric mods (#13253).
The mod support changes mentioned in our last news post are now also complete, and the new mod template has reached feature parity with the old modding setup.  This has been a major task that will make life significantly better for modders, once they get over the initial learning curve.

Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic Page 4 of 4 [176 Posts] Goto page: Previous 1, 2, 3, 4
View previous topic :: View next topic
 Forum index » Modding Central » OpenRA Editing Forums
Jump to:  
Quick Reply
Username:


If you are visually impaired or cannot otherwise play the game below please contact the Administrator for help.


 
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © phpBB Group

Wildcard SSL Certificates
[ Time: 0.2288s ][ Queries: 12 (0.0890s) ][ Debug on ]