I'm wondering how to do the
devlog(s) from now on…
- wants to be in the wiki
- does NOT want to be a separate log for engine/tools/cauchemar/gnome.For release logs yes, but not devlogs
because I'll be tending to flit between engine, tools & project a lot and
don't want to lose the 'trail'.
- however, some kind of colour-coding to indicate the thing being worked on
at each part of the log would be nice.
- wants to be a log per PERSON
choice therefore seems to be between:
- devlog as a sub-page of the user page
- devlog as a namespace
Decided the devlog should be a sub-page of my user page.Here it is:
http://programmerart.org/wiki/index.php?title=User:Phil/Devlog
This Excel devlog is now discontinued.Please follow the link above for the new devlog on the wiki.
8-mars-2010
4
Let's work-out why the .X
exports from Max 10 aren't working (appearing invisible)…
Tested opening a Max file saved
from max 6 with max 10: works perfectly.
Test: Saved the same geosphere,
with the same export settings, from both max 6 & 10:
c:\gnome\exporttest
…hmm, neither the 6 nor the 10 version shows up in the DX viewer.
Let's try in-game…..
The 6 version isn't showing up in game.
Let's try exporting Tubby from 6...
interesting, he exports, with his anims, but he's lying on his front with
his head facing back behind the player.
Try exporting him from 10...
loading him in 10, there's a message saying "obselete data found,
please resave file"
Weird! (but cool) - saving from 10, tubby works perfectly, he's standing up
this time.No idea what was wrong with
the 6 export, never seen that problem before.
Guitar exported from 10: still
invisible.
Think this might be a bones thing.
Gnome exported from 10: invisible.
Now waiting for Graeme to send me a max 10 zombie in .max format.I'll export him as a binary X and release
him in a new build of Le Cauchemar.
Right, while I wait for the new
zombie model, I'm going to improve the Options Parser tool so that it spits
out wiki documentation for all the options it processes.
#revision 2018
The Options Parser tool now
outputs wiki documentation for all the options it parses (using the code
comments).
The page that it generates is currently
(C:\noctambule\docs\WikiOptionsList.txt), which goes here in the wiki:
http://programmerart.org/wiki/index.php?title=Engine:Engine/Options/List
#revision 2020
The wiki documentation generated
by the Options Parser now includes the lists of available enumeration
values.
TODO: Include the comments for the enumeration values.
1-mars-2010
1,5
Grrr, my bug from yesterday was
just the old chestnut of confusing 'view matrices' with view-to-world
matrices >:(
How embarrassing.
Made a rule about this now in my coding conventions:
Fixed the culling of objects in
the ground reflection.
Dug-out the old TrackIR 4.It gave me a couple of bluescreen crashes
when I connected it to my USB two-way splitter.Seems happy enough connected directly to a
USB port though.
Tested that it was being handled properly in v23.2 and in the current
code.
TODO: fix shadow glitches seen at the edge of the screen when the tracked
head is off-centre.
28-févr-2010
1,25
trying to fix the culling of
reflected objects….
- In TestSphereVisibility, see the two versions of the setup of
pInvCameraMat.The second is the one
I'm trying to get working.
- See current changes in CModeEnvironment::GenerateReflectionImage.Why is that reflected matrix not working
for TestSphereVisibility?
21-févr-2010
0,5
#revision
2012
#revision 2013
wiki: Fixed the page script
errors.Not sure what the proper fix
would have been; i've just remmed-out the references to these undefined
variables :
wgBreakFrames (now as if false, revision 2012)
wgContentLanguage (ts_europeandate is now always true, revision 2013)
#revision
2014
website: added 'wiki' link to
the links at the top of the home page
#revision 2010
wiki: removed copyright &
powered-by stuff from the page footer
wiki: installed this
syntax-highlighter extension; can't get it to work….
http://www.mediawiki.org/wiki/Extension:SyntaxHighlighterAndCodeColorizer
programmerart.org was framed to
http://www.philpalmer.me.uk
can't figure out how to make
programmerart.org point to programmerart.org/wiki
14-févr-2010
NOTE: When making changes to
style sheets, need to Ctrl-F5
to be sure that the changes take effect!
#revision 1997
baseTemplate.css: #mainContent
:
float: none
width: auto
#revision 1998
intech: properly fixed the
content wrapping problem now, by copying some of the 'basic structure'
section from the basetemplate.css of the Cavendish theme
#revision 2003
simplified the sidebar a little;
changed it to use pngs
The site is a ton snappier
speed-wise now that I've changed all the jpgs to pngs.Jpgs are real slow.
"__NOEDITSECTION__"
anywhere on the page will remove the edit links
http://www.mediawiki.org/wiki/Extension:Edit_Section_Link_Transform
this is supposed to replace the [edit] links with an icon.Doesn't work for me - prevents the pages
loading, in either intech or monobook skins.
got the section [edit] links
behaving themselves with the intech skin.In the main.css, I just had to add style entries for
"h1.editsection", "h2.editsection" etc.I also had to add "float:right;"
into each of these, although I had thought that the "float:right;"
in shared.css should have already taken care of that.
# allow inline images hosted on external websites, sometimes called Inline
linking.
$wgAllowExternalImages = true;
13-févr-2010
wiki: no idea why I can't get
the 'editinterface' permission to work (to edit the page
'MediaWiki:Sidebar').
I'm registered as an admin, and Special:ListGroupRights confirms that
admins have the editinterface permission.
But I can't edit the sidebar page; there is no edit tab.(?)
...AHA: I can edit using this link:
http://programmerart.org/wiki/index.php?title=MediaWiki:Sidebar&action=edit
Spent ages trying to prettify
the urls, so that for example
http://programmerart.org/wiki/index.php?title=Main_Page
would be
http://programmerart.org/wiki/Main_Page
Couldn't get the .htaccess file (in wwwroot) to have any effect.Sent a note to Catalyst2 asking if this is
possible and if I'm doing it right...
hmm, pas de bol :
"Hi Phil,
I am afraid .htaccess doesn't work on windows hosting, just our linux
packages."
"If you're planning to use PHP and MySQL, then a Linux account would
probably suit you better."
TODO: switch to Linux hosting once the old site
is dead?
wiki: Been wrestling with the
dilemma of namespaces vs no namespaces.
With namespaces (for Engine, Tools, Le Cauchemar and Gnome), we can filter
the search, which is really nice I think.
The downside is that Engine page can't be called 'Engine', it has to be
called something like 'Engine:Main' or 'Engine:Engine' :/not great.
Decided in the end to go with the namespces; the search-filtering is too
nice a feature to lose.
The namespace root pages are therefore called:
Engine:Engine
Tools:Tools
Le Cauchemar:Game
Gnome:Game
Not great, but my opinion right now is that it's the best compromise
overall.
Cool, an extension to hide page
titles:
http://www.mediawiki.org/wiki/Extension:NoTitle
"Just put __NOTITLE__ on any pages where you want
to hide the title."
Didn't manage to get NoTitle
working for the intech skin.TODO:
clean-out the unsuccessful test code.
10-févr-2010
had a look at wikispaces
and Zwiki:
http://zwiki.org/ZwikiInANutshell
This allows a hierarchical layout (nice backlinks etc), but not
hierarchical naming.
Helm: Set PHP version to 5 (in
the website settings).This is in
preparation for potentially using the latest version of MediaWiki
test: website write permissions
= yes
test: show folder sizes = yes
I think Catalyst2 has got
everything I need to run a MediaWiki site:
"Required software:
* Web server with PHP 5.x or higher.
* A MySQL server, 4.0.14 or higher OR a Postgres server, 8.1 or
higher"
so I'm going to try MediaWiki…
It's all about those sub-pages…
I've already downloaded
mediawiki-1.15.0.tar.gz
and unpacked it.
Renamed the remote root folder
for the ScrewTurn site to
"ScrewturnWiki"
MediaWiki 1.15.0
Installation
Don't forget security updates! Keep an eye on the low-traffic release
announcements mailing list.
Checking environment...
Please include all of the lines below when reporting installation problems.
PHP 5.2.8 installed
Found database drivers for: MySQL
PHP server API is cgi-fcgi; using ugly URLs
(index.php?title=Page_Title)
Have XML / Latin1-UTF-8 conversion support.
Warning: A value for session.save_path has not been set in PHP.ini. If the
default value causes problems with saving session data, set it to a valid
path which is read/write/execute for the user your web server is running
under.
PHP's memory_limit is 128M.
Couldn't find Turck MMCache, eAccelerator, APC or XCache; cannot use these
for object caching.
GNU diff3 not found.
Found GD graphics library built-in, image thumbnailing will be enabled if
you enable uploads.
Installation directory: D:\domains\programmerart.org\wwwroot\wiki
Script URI path: /wiki
Installing MediaWiki with php file extensions
Environment checked. You can install MediaWiki.
contact email was:
root@localhost
language was en-English
copyright/license was: No license metadata
admin username was: WikiSysop
bought a 25MB MySQL 5
database
Added it in Helm as "wikidb"
Added the "wikiuser" user
done: "Move the config/LocalSettings.php file to the parent
directory"
todo: "You should change file permissions for LocalSettings.php as
required to prevent other users on the server reading passwords and altering
configuration data."
LocalSettings.php: added:
# Enable subpages in all namespaces
$wgNamespacesWithSubpages = array_fill(0, 200, true);
big w00t !The MediaWiki site is working and sub-pages
are working.
http:\\programmerart.org\wiki
10-févr-2010
22h23
It would appear that I has
wiki!!!!1
Previous wiki header:
<div style="float: right;">Welcome {USERNAME}, you are in:
{NAMESPACEDROPDOWN} •
{LOGINLOGOUT}</div><h1>{WIKITITLE}</h1>
Server
Error in '/wiki' Application.
--------------------------------------------------------------------------------
Configuration Error
Description: An error occurred during the processing of a configuration
file required to service this request. Please review the specific error
details below and modify your configuration file appropriately.
Parser Error Message: Theme 'Custom' cannot be found in the application or
global theme directories.
Source Error:
Line 36:<trace
enabled="true" localOnly="false" />
Line 37:<!-- -->
Line 38:<pages
styleSheetTheme="Custom"/>
Line 39:
Line 40:<customErrors
mode="Off"/>
<- TEMP: to fix the problem
above (without damaging the current active site), I've added the folder
wiki/App_Themes, which just contains an empty Default.css.
TODO: once I drop the current main site in favour of the wiki, I should
delete this folder.
Doesn't look like I can do
MediaWiki-style subpages with ScrewTurn Wiki :(
Andy Henderson, Screwturn developer:
"Basically, Wikis are good at handling
unstructured data and mapping structured data onto a Wiki can be frustrating.
If you use a page naming convention to allow a page to identify its subpages,
you could consider writing your own plugin to do the connecting up
automatically."
NOTE: with MediaWiki's subpage system, it's not
difficult or frustrating at all!
Really want to set up a wiki
before I do anything else.Documentation is really valuable.
Tested wetpaint.com (provider of free hosted wikis).Sucks - plastered in muscly-man/dating
adverts.
$19.95/month to remove the ads.
Installed Emerald Viewer
(replacement Second Life viewer).
g:\Program Files\Emerald Viewer
Downloaded Screwturn Wiki
no-database-required version:
File-System Data Storage
ScrewTurn Wiki 3.0.1.400, pre-configured for storing data on the local
file-system. Optimized for easy deployment and for low-traffic wikis.
Deleted the old wiki test
folder:
wwwroot/wiki
Recreated wwwroot/wiki and will
use it for ScrewTurn
Following the "Clean Installation" instructions:
G:\Installs\ScrewTurn Wiki\ScrewTurnWiki-3.0.1.400\install.txt
TODO: 4. Set the permissions of the
"public" directory so that the ASP.NET Worker Process has
"Modify" permissions on it (usually, the
ASP.NET Worker Process runs as "NETWORK SERVICE" or
"ASPNET", depending on the Operating System
version).
5. Setup a Web Site or Application
in IIS, setting the root directory to TARGET_DIRECTORY.
6. Navigate to the Web Site or
Application using a web browser and verify that everything works properly.
Found the cause of the
ineffective-interlaced-pixel-shift-on-menus problem:
The menus are not drawn to the (half-height) frame RT.They're drawn directly to the screen, using
a z-buffer mask in certain stereo modes such as interlaced.
CViewInfo::ApplyCamera: tidied
the zero-parallax-distance test so that it can be left in (it's not useful
for this game but good reference for the future).
Added the required one-pixel
offset for the second eye in line-sequential and column-sequential stereo
modes.
#revision
1983
bugfix: COptions::LoadOverrides:
The correct default override profile is now loaded when column-sequential
stereo modes are selected.Previously
the line-sequential override was getting loaded instead (cut & paste
error).
23-oct-2009
3,333
#revision
1978
Example_3DDisplay_Zalman_Trimon_ZM-M190.txt
now uses an accurate screen width measurement: 37.5cm
#revision
1979
Added missing source files to
the install:
Frustum.cpp, Frustum.h
MaterialTexturePathnames.hpp
Checked that all other releasable CPPs and headers are present.
Found John Whigham's public Isis blog (not updated since May
2009 unfortunately) :
http://genesis-machina.net/wordpress/?cat=4
#revision
1980
ETEXTURE_ZOMBIE
has been replaced by
ETEXTURE_CHARACTER_TUBBY
and
ETEXTURE_CHARACTER_GRACORE
#revision 1980
Added option Debug
\ playerCharacter and Debug
\ enemyCharacter
Valid values are currently ECHARACTER_TUBBY or ECHARACTER_GRACORE
Both options default to Gracore.The
Gracore model is currently over-expensive, but it looks tons nicer than the
old placeholder zombie, so it's got to be the one we use by default.
26-sept-2009
#revision
1973
#revision 1975
Added profile Example_3DDisplay_Zalman_Trimon_ZM-M190.txt
This uses a rounded
screen measurement of 44cm from invincibletiger.com
(can't find my measuring tape)
<-FIXED (23.10.9)
23-sept-2009
Bought the domain name stereoshare.org for one year.This is for the photo/video viewer that I'm
going to make, that will allow (as an initial goal) stereo photos from my
Fuji W1 to display optimally on a Zalman ZM-190 with no hassle.
The idea is:
- select camera
- select monitor
- look at photos (they're correctly calibrated for the camera-montior
combo) - no hassle.
TODO: Advertising deal for 3D monitors.
TODO?: This viewer could allow head-tracked viewing of 360x180 panorama
photos (very cool).
_ground
is now a subdivided, rippled plane at 0,0,0
7-juin-2009
6
#revision
1884
Fixed a silly bug that was
causing the 3DVisor custom override profile to get loaded in place of the
iWear one.
The iWear custom override profile now works.
#revision
1885
DXUT: I'm now calling the
device-lost callback at every point in the file where SetDeviceLost(true) is
called.
A few of these cases are rare and never get tested... :/
AdapterOrdinal
Fixed the crash I was getting in
VR920 mode when dragging the game window between monitors:
#revision
1886
The failing assert (in
DXUTSetMultihead: "NumberOfAdaptersInGroup > 1") was actually
invalid so I've removed it.
Explanation from DX docs:
"NumberOfAdaptersInGroup is 1 for conventional
adapters, and greater than 1 for the master adapter of a multihead card. The
value will be 0 for a subordinate adapter of a multihead card. Each card can
have at most one master, but might have many subordinates."
#revision
1887
The crash that followed the
failing assert was in CLamppost::Prep, where it was assuming
'this->pLight' was non-NULL.pLight
is set up in the Update (todo: move), so it must have been getting to a prep
before an update.Thought this might
have been because of the frame-sequential style ("more
synchronised", don't update between the eyes), but it was happening on
"smoother" as well.
Anyway, fixed with a NULL check.
The iWear default override
profile now sets displayWidth=30, distanceToScreen=40.
Might be too strong for some people; let's wait and see what they say.
#revision
1889
Z800 & VR920 example
profiles now set fullscreen=true, fullscreen res = 800x600
#revision
1890
Added option display
\ adapterOrdinal (defaults 0)
This allows you to specify the index of the adapter (monitor port) for
which to create the D3D device.
When the value is used, it is clamped between zero and the index of the
highest available adapter.
Described the geometry of
accurate life-sized stereo in an MTBS post (handy info):
http://mtbs3d.com/phpbb/viewtopic.php?p=26175#p26175
#revision
1891
The Z800 & VR920 example
profiles now set display \ adapterOrdinal to 1 (so they assume that the headset is the secondary
monitor).
#revision
1892
Added option headTracking
\ ignoreYaw.Ignore headtracker yaw values (only applies to iWear)
Defaults false / true when using iWear headtracking.
#revision
1893
Moved headOffsetMatrix setting
from OptiTrack custom override profile to OptiTrack default override
profile.
No idea if the data is good or not, but at least now it's the in the right
file.
Added missing profile Example_HMD_eMagin_Z800_3DVisor.txt
to the install
6-juin-2009
1,5
#revision
1882
Graeme's going to take over the
art & design for this project, because I don't seem to enjoy
modelling/texturing/animation enough to get good/fast at it any time
soon.
I've burnt him a DVD containing all the current artwork, photography and plugins.He might need to throw away the existing
landscape because the unconventional way I've approached the modelling (huge
towering modifier stacks that I never collapse) might not suit him.I've got no problems with starting the
scenery from scratch, as long as the results are better than mine.
We'll set up a workflow that will allow him to test his work easily in-game
as he goes along.The aim is to get
from what we have now - a sparse engine demo - to a presentable finished
game.Then we'll start on the next one
;)
TOFIX: game now crashes if
dragged from one monitor to another, except (if you're lucky/fast) if this is
done during startup.
<-Fixed(7th)
"Anyone that wants a screen grab of the sensio format, just email me
at *******
Basically it is side by side squeezed 720x480 image with a 6 pixel vertical
black border up the middle of the 2 images. The image on the left is 360 pixels
wide, then the 6 oixel border then a 354 pixel image on the right"
1-juin-2009
1,25
These settings make the VR920
mode awesome:
displayWidth: 30 // bizarrely small, was 100
distanceToScreen: 40 // bizarrely small, was 150
iWearUnleashed:yes // 60fps
ftw
frameSequentialStyle:EFRAMESEQUENTIALSTYLE_MORE_SYNCHRONISED // really just for the blaster
effect
Above: re the 30 & 40:
interesting, that, very interesting.I
think what's happening is this:
- the field of view is being exaggerated (which is nice except it makes
things more miniature)
- at the same time, the horizontal image translation is also being
exaggerated (which stretches the Z axis)
- the combination of the two keeps everything looking approximately
life-sized, but more juicy than it would be if using the true values.
...something along those lines.Need
to be able to explain it more scientifically.But the important thing is that it feels a load more immersive than it
did before.Of course, there could
just be a bug somewhere in my maths, but that's not my gut feeling (and any
such bug would need to have been hiding pretty hard through all the
headtracking etc).
So I think I've stumbled on something quite useful here - just need to make
a bit more sense of it....
TODO: for v23.2: use the 30
& 40 (above), see what people think of it.
<-done(7th)
TOFIX: in v23.1, in VR920 mode,
trying to override displayWidth / distanceToScreen:
customOverrides_EHEADTRACKERMETHOD_IWEAR.txt doesn't seem to work;
custom.txt doesn't seem to work !
<-fixed (7th)
31-mai-2009
5
Visual Studio: kept getting that
"Embedding manifest…" hang, which requires a restart >:(
When I interrupted the hang by
trying to shutdown Windows, I got this:
"1>Project : error PRJ0002 : Error result
-1073741510 returned from 'C:\Program Files\Microsoft Visual Studio "
#revision
1877
Managed to get fullscreen
alt-tab working in VR920 mode.
Found that DXUT hadn't actually been calling my device-lost callback… it's
very tricky to debug fullscreen problems when the VR920 is my primary
monitor.
Incidentally, the matrices sample crashes on fullscreen alt-tab.
Found the source of the slowdown
in VR920 mode.It's in
CiWear::PostPresent, the 'while' that waits for the eye queries.If I rem that out, the framerate rips back
up 60 but the synchronisation relies on it staying at 60 (just like the
Z800).Sooo much nicer in 60.
<-added an option to skip the while: "VR920 max speed"
(stereoscopy\iWearUnleashed)
TODO: See if there's a better place in the frame for
that 'while' (maybe in PrePresent???)
Trying to get fullscreen alt-tab
working in VR920 mode…
25-mai-2009
3,25
#revision
1873
#revision 1874
Added option stubs:
- stereo \ sceneScale
- stereo \ smootherFrameSequential (update between first and second eye in frame-sequential
modes).Currently Iprefer it 'smoother' (but less
synchronised).Need to compare the two
versions on a faster PC if possible.
#revision
1875
Option stereo
\ smootherFrameSequential now works.Defaults true.
TOFIX: if game is launched in
fullscreen, the fullscreen res specified by the HMD override profiles doesn't
take effect because the HMD is detected later than the display being set up.
TODO: fullscreen alt-tab
handling (enter pause mode and pull the VR920 out of stereo mode.
21-mai-2009
5,5
TODO: Find out how the options
"head-mounted display" and "camera mounted on monitor"
sit with each other.
Plus other improvements to the mix-and match configurations (keep the Z800
awake, etc)
Had to add an iWear case to
COptions::LoadBasicProfiles, otherwise changing the stereo mode would set the
HMD option false.
TODO: some tidying (see duplication of profile loading between
COptions::LoadBasicProfiles and CHeadTracker::Init)
…also fixed a bug in
COptions::LoadBasicProfiles that was preventing the 3DVisor custom override
profile from being loaded.
Forced the VR920 into mono when
windowed.TEMP?
I couldn't get it to sync properly in stereo in winodowed mode.Even the Matrices sample doesn't manage to
do this reliably.So it's probably not
worthwhile trying to fix it.
Got rid of the messages saying
that the VR920 is not connected to a video adapter (it was appearing
erroneously, even in the Matrices sample).TODO: put them back in?
Got the eyes into sync on the
VR920.Just had to move the query
Issue calls to be around the entire BeginScene-EndScene section
(OnFrameRender, main.cpp)
Found that the VR920
headtracking pitch and roll are almost perfect.It's just the yaw that's unusable.
TODO: add an 'ignore yaw' option that defaults true in the VR920 profile?
At 640x480 fullscreen, the game
has some strange tearing at the bottom of the screen in VR920 stereo
mode.
Tested the 'Matrices' sample from the iWear SDK - it does exactly the same
thing in 640x480 :P
So I'm going to forget about it and set the default fullscreen res in VR920
mode to 800x600 (same as Z800).That's
good for a couple of reasons - gives us a sort of antialiasing and prevents
me getting any false impression of how well the game is performing GPU-wise
(as would be the case at 640x480).
So tomorrow, version 23 - with
VR920 native support, finally :)
19-mai-2009
3,5
Remembered there is no Mist.fx
anymore.The mist is currently
rendered in DeferredLightingApply.fx
The problem with loading the
iWear DLLs (16th) looks like it was [mostly] just a unicode/non-unicode
mixup.I hadn't noticed a compile
warning 4133 telling me that the DLL filenames were ASCII which was invalid
input for LoadLibrary.
The other weirdness there was that the debugger was showing faulty values
for variables (so even once it started working, it still appeared in the
debugger as if LoadLibrary was returning NULL)
Global.h, added:
#pragma warning(error:4133)//
PP(19.5.9): warning C4133: 'function' : incompatible types - from 'char [13]'
to 'LPCWSTR'
Also added this separately to iWearSDK.c
Added
CiWear::InvalidateDeviceObjects & RestoreDeviceObjects
Device changes now work (eg. Alt-enter to non-desktop res)
Tested AssaultCube in VR920
native mode.Works…although I got the
impression the headtracking yaw was being doubled maybe?
Progress!Headtracking is working; stereo is working
fine in windowed mode but the eyes are switching in fullscreen.Shouldn't be too hard to track that down
tomorrow.
Ouch!The VR920 just took its first tumble onto
the stone floor (drop of about 1.5 feet).Thankfully the screens still look fine.I might stick some bubble-wrap on it.
18-mai-2009
0
TODO: for sound, find out about
IXACT3Engine - something built into directX / xna
16-mai-2009
5
Teehee, a great name for the
sequel: Cauchemardeux !
Added to project Configuration
Properties \ C/C++ \ General \ Addition Include Directories :
C:\IWEARSDK\inc
WM_MOVE and WM_SIZE messages are
sent automatically when the app starts up
Couldn't get LoadLibrary to work
for iweardrv.dll - no idea why; it works fine in the samples
So I'm now linking statically with iweardrv.lib instead
Same for iwrstdrv.lib
<-FIXED (19th), and the static linking didn't seem
to want to work anyway
Added
C:\IWEARSDK\lib
to VS library paths
15-mai-2009
4
TODO: Why on earth is some of
the stuff (menu, rain) rendering in anaglyph now when in fullscreen???
And where are all the character/lamppost shadows???
Must be because of the video driver update?
->oops, the nvidia stereo driver had somehow got activated, panic over
#revision
1858
Vuzix SDK: Successful upgrade
from 2.1 to 2.4
TOFIX: custom override profiles
are currently built from my dev versions.Need to do the same as I did with custom.txt
#revision
1861
CCamera::CalculateProjection:
removed a variable that was being used uninitialised…very worrying.Need to test window headtracking
asap.
Problem started in revision 1843, meaning it was released in v22.1
Shadows are getting cut-off at
the edges of the screen (debug and master), although 22.1 was fine.
Conclusion: revision 1843 corrected the frustum face orientations but it
pushed the near face out to the screen plane.As a result, when the distance-to-screen is low the shadows become
blocky; when distance-to-screen is large the shadow culling causes gaps at
the edges of the screen.
<- fixed in revision 1864
#revision
1864
Corrected the g_viewInfo.cameraSpaceViewFrustumso
that it now matches the the actual frustum used for the projection.The result is that no shadows are cutting
out or getting blocky, etc.
TOFIX: in side-by-side modes,
you can see some wrapping of the rendertargets at the edges
TODO: Stereo scene-scale
parameter, just for fun / completeness.Could be interesting with the headtracking actually.
TODO: Follow that with a focus depth parameter (for the same reasons), and
even an auto-focus (for the same reasons)?
14-mai-2009
0,83333
Been away for a while.The purpose of this project was to help me
apply for a job somewhere French-speaking, and back in December that all came
to a successful conclusion (I'm now in France rather than the UK... YHESS!)
I've been a bit busy with the move, the new job etc.But the side-project 'bug' isn't easily
shaken off (nor is the stereo 'bug') - I've missed it.So I'm coming back to do some stuff... but
hopefully I won't let it absorb me quite as much as it did before.
I've just bought a Vuzix VR920
HMD, so it's time to put the native support for that into the game.From what I can tell, the headtracker is
pathetic, but the screens are quite nice.
Downloaded and installed the
VR920 Windows SDK v2.4 from here:
http://www.vuzix.com/support/downloads_drivers.html
Installed 2.4 over the 2.1 that was already installed and in SVN
Tested the HelloTracker2 sample
project - seems to be working fine.
MatricesQueryGPU sample:
1>Linking...
1>MatricesQueryGPU.obj : error LNK2019: unresolved external symbol
_D3DXCreateFontA@48 referenced in function "long __cdecl InitD3D(struct
HWND__ *)" (?InitD3D@@YAJPAUHWND__@@@Z)
1>Debug/VR920StereoScopy.exe : fatal error LNK1120: 1 unresolved
externals
11-déc-2008
2,5
#revision
1841
#revision 1842
Added new options
profiles:
- Example_HeadTracking_OptiTrack_FLEX_V100.txt
- Example_Stereoscopy_50Inch3DDLP.txt
- Example_Stereoscopy_Speedy_50Inch3DDLP.txt
#revision
1843
Camera.cpp: Made a further fix
to g_viewInfo.cameraSpaceViewFrustum, continuing from revision 1839.
The near (small) end of the frustum represented by it now simply matches
the screen rather than the near clip plane.
This fixes a bug that had been remaining whereby objects and shadows would
still sometimes cut out at the edges of the screen when using headtracking.
Remembered that you can't
[always] breakpoint 'goto' lines :/
For this reason I've now removed all the gotos from
CMeshFrame::TestVisibility
OptiTrack: The hang I've been
getting, when using the Flex V100 camera, is in
pCameraCollection->Enum in COptiTrack::Init.
It makes the game process impossible to kill from task manager.
Removing the USB fixes the problem straight away.
#revision
1839
Took me a while to track it
down, but I've now fixed the annoying culling & shadow glitches that I
was seeing when using virtual-window headtracking and moving the viewpoint
well off-axis.
I had been forming the off-axis frustum using the camera-space eye position
as the origin (the tip).
However, I had been generating the face planes using that tip and two
points on the near clip plane (rather than points on the screen plane).Effectively I had been generating frustum
data for a smaller screen (a screen the size of the intersection between the
near clip plane and the frustum).That
had been producing incorrect plane equations for the frustum's faces.
I'm now scaling the tip position by (nearClip / (distance to screen when
head is centred)).The near end of the
frustum still sits on the near clip plane.
7-déc-2008
2,5
#revision
1836
Fixed the bug that was stopping
the headtrack offset matrix being saved.It's now saved to the headtracker's custom override profile when the
headtrack calibration mode is popped.
TODO: fix problems with options
being set by stereo default overrides, eg. Aspect ratio & IP distance for
cross-eyed.
2-déc-2008
2
Bit of modelling: did the
Bedford Court window pod.Used 'fixed'
window primitives for this; they worked well.
23-nov-2008
12,666
todo get skydome collision
exclusion working
Shadows now use a 4*4 blur pass
after the screen-res scattering process - the result is very clean soft
shadows.Scattering now uses a
repeating 4*4 pattern so that it blurs neatly.The repeating scatter pattern also improves
texture cache efficiency lots (at least, it did last time I tested it).
Shadow dest RT must now always be a quarter of the width & height of
the shadow source RT.
#revision
1824
#revision 1825
Parallax.fx: Fixed the shadow
gaps seen where geometry intersected a parallax surface.
The fix makes parallax.fx output a slightly untrue position value (as if
the POM peaks were poking out instead of the troughs poking in).But there are no side effects that I care
about in the slightest.
#revision
1831
Added a subtle ambient occlusion
effect to the shadows, by making them get slightly weaker as they move away
from the point where the occluder touches the receiver.
I don't know if I'll be able to keep this or not… it's totally beautiful in
the areas where it works, but when there's busy mesh detail (eg. characters)
it causes artefacts.I'll keep an eye
on it....
#revision
1832
Added option Debug\exhibitLighting.This shows the scene with no textures.
I may have fixed the problem
where the lighting would occasionally jitter out of position for one frame at
a time.
I'm confused about the problem; I'm also hoping it could be a possible fix
for the no-lighting-at-all bug seen by CK.
I had a hunch that the problem was to do with getting the current render
target dimensions (with pSurface->GetDesc) in order to set the half-pixel
offset constant for DeferredLighting.fx.... some kind of contention
thing....?
I've now changed most of
those places to use the width & height members of the CRenderTarget
instead.
#revision
1832
Are all of the following
rendertargets cleared if required? :
- shadow source? - clear needed and done.Barely needed, but without it, a clipping glitch leaves smears on the
player's hands (TODO: find nicer fix?)
- shadow dest? - clear not needed and not done
- splash source? - clear needed and done
- splash dest? - clear not needed and not done
Temp v24 bodge: Mesh frames now
default to drawing to rain occlusion again (there's a bit more work involved
in letting it default false…TODO!)
Disabled the placeholder weapon
sound.It's been nothing but trouble
from day 1.I'll add proper audio if I
get a chance.
Grr, since updating my DirectX
SDK, HLSL syntax highlighting is not available:
http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=1324043&SiteID=1
I can't see what I'm doing without syntax highlighting :(
#revision 1815
Fixed the bug in the new shadow
softening.The first sample had been
getting no position offset, because of the ordering in the loop.
#revision 1816
<- nice accident that causes
trees to cast multi-layered shadows (they're not usable though)
#revision 1820
The new shadow softening is now
much more geometrically accurate.Takes into account the light-to-occluder distance, light emission
radius, and occluder-to-receiver distance.Looks very concincing.
#revision 1821
Improved the dynamic shadow
frustum by making the far distance adaptive as well as the near
distance.This is good for two
reasons:
1. it greatly increases the apparent resolution of the sharp shadows
2. it reduces the amount of redundant casting geometry used.
#revision 1822
Further improved the dynamic
shadow frustum by adding new rays for the intersection tests:
- left side
- right side
- top-left
- top-right
- top centre
It's still one ray-test per frame, so there's no increase in cost.
Scenic modifier: 'Draw to Rain
Occlusion' now defaults FALSE.
MeshFrame.h: Mesh frames are now excluded fram rain occlusion render by
default.
Scenic modifier: added an
'Enable Collision' property.Currently
defaults TRUE.
The placeholder skydome no
longer has collision enabled.It had
been reducing the effectiveness of the dynamic shadow frustum.
17-nov-2008
1,5
There is something screwy with
the first two iterations of the PS loop in ProjectorShadow.fx.
See temp test "if( i > 1)"
Try reordering or unrolling.<-FIXED(22nd)
16-nov-2008
8,45
Had an idea for speeding-up the
FFSM shadows: when each face samples the position buffer behind the lighting
geometry, it could write a value to a Z buffer if the pixel landed within its
frustum face.This Z value would then
block-out the passes for subsequent faces so they wouldn't need to run the
pixel shader for pixels that don't concern them.
I tried it, and I'm a bit confused by the results....
…Z test and stencil test happen
AFTER the pixel shader
(http://www.gamedev.net/columns/hardcore/dxshader3/pipelinegr.gif).So presumably the idea was flawed from the
start.
However, I found that if I cleared my Z buffer to 0 (so all lighting would
be occluded), I got the kind of speedup I was originally expecting - but only
if the vertex shader outputs
the depth value rather than the pixel shader doing it.I've got no idea what kind of crazy magic
is going on there.
…Then I tried clearing the Z
buffer to 1 and letting the lighting plant its proper depth values in the Z
buffer so each face pass should partly occlude subsequent face passes (the
way it should work).This didn't give any speedup.
…'clip' does work as an
optimisation.
Hang on, the whole reason for trying this Z-buffer optimisation was that my
early (very rough) test showed 'clip' NOT working as an optimisation.I just wasted half a day!It's a good thing no-one reads this
devlog.
The final check-in for this experiment is revision 1808.
Removed in revision 1809.
Aha!Finally worked out why my keyboard keeps
randomly switching to AZERTY: it's whenever I accidentally press left-alt +
shift (the shorcut to change input language).Now fixed.
#revision 1808
Had to change the reflection RT
back to half-by-half.It's used for
fallback shadows, for which quarter height is too blocky :(
TODO: compare performance both ways
TODO: clear the rain splash
RTs!!!!!!!
The game project is taking
forever to "embed the manifest" today.No idea what's going on there.I'm in Master config.
TODO: When the headtracker
connection is lost, and the player chooses to cancel (continue without
headtracking), the headtracking transform needs to reset.
#revision
1810
#revision 1811
Fixed a bug that had been
causing nasty random overdraw for ProjectorShadow.fx.
CProjector::GenerateShadows had been drawing the light's geometry
using
LIGHTMANAGER_PRIMS_PER_LIGHTING_STRIP
rather than
this->pLight->numPrims
I've now changed that define to a private static member of CLight
(s_numPrimsPerLightingStrip_withTail).
This evening I've been improving
my shadow softening, as you'll see in the next release…..
15-nov-2008
4,8
Max X exporter: Although 'use
full pathnames' doesn't have any effect on texture names in effect instance
blocks, it does affect the FX filename.
Had to un-tick it to go back to exporting just FX leafnames.
The game is now loading again.
#revision
1792
Profiles: The horizontal res now
defaults to being halved (frameRT:[/2,/1]) in checkerboard and iZ3D stereo
modes.This isn't ideal, but keeps the
performance more consistent with the other modes.
Had to set my PC clock forward
an hour, because it had jumped backwards a few days ago.I expect it's using French DST or
something?
Rain splash
source & dest RTs no longer share with
Mist RT now defaults to full
screen res.This removes quite
noticeable blocky edges on lampposts etc.
Reflection RTs now default to
half screen res and quarter screen height (previously half by half).<-had to change back (16th, #1)
Changing shadow RTs from 1/2
& 1/4 to 1/1 & 1/2, with two projectors, debug:
45.75 fps becomes 44 fps
Not a very scientific measurement, but it gives me some idea of the damage.
SVN: deleted graphics files from
their old locations.
SVN: added graphics files in
their new locations.
11-nov-2008
3
Did away with UtilFindMediaFile,
which I'd been meaning to do for a long time.
The auto-generated inventory (MaterialTexturePathnames.hpp) is now being
used instead.
Set up the new structure of the
installer.This is almost working now.
10-nov-2008
3
To output a directory listing to
a file (which I was trying to do a while ago for the code conversion tool)
:
in C:
system("dir C:\\noctambule\\source\\HLSL\\*.fx /b
>> C:\\noctambule\\tools\\ShaderBuild\\fileList.txt");
in DOS:
dir C:\noctambule\source\HLSL\*.fx /b >>
C:\noctambule\tools\ShaderBuild\fileList.txt
Added a new tool called Inventory, whose job is to parse
the VDPROJ (setup project) file and spit out various handy data for me:
1. an ordered table of the CRCs and full filenames of all the textures in
the install (MaterialTexturePathnames.hpp).This is needed because the X file exporter for Max only outputs
texture leaf names for
the material instances >:(It's a
handy table to have anyway, because at load time I can now assert that each
texture being used has been added to the install.Is there even the possibility of putting
custom properties on the textures in the setup project now???
...2. (TODO): 'mega source
file', a concatenation of all my source files.That can then be pasted into Dev Studio (so
it gets syntax-highlighted), and from there into Word, then exported as
nicely-formatted HTML.A separate tool
(or maybe the same one) will then chop that up into an HTML file for each
source/header file; those HTML files will go on the website.I'll probably auto-generate a nice index
page for the source code too (each filename as a link, with its description
next to it).
9-nov-2008
5,33333
Lamppost: Must be exported with
'optimization' set to NONE, otherwise the skinning gets messed up.
Non-animating meshes should be exported with it set to OPTIMIZED (otherwise
the exporter seems to hang on 'animation sets').
#revision 1784
Removed the Graphics\Final
folder
X file exporter: Ticked 'Use
full pathname' on the 'Textures & .fx files' tab.
…but it's still just writing out leaf names for the textures in the
EffectInstance blocks >:(
Wondered if there might be an
annotation that would persuade the exporter to export full texture
paths.
Nothing mentioned here:
http://developer.nvidia.com/object/using_sas.html
Updated Panda X exporter to
4.6.62.0
Same problem with the texture filenames though.Hmm…..
Made lots of improvements to the
game's file/folder hierarchy.Files
that used to be loose in Graphics\Final are now properly categorised into
Graphics\Effects\... and so on.
8-nov-2008
10,5
I've been trying all sorts of
ways to position these Xref'd buildings (and their child objects) into the
town scene in such a way that they're well-behaved and easy to maintain.I seem to have got something that works now
for BC:
- made a mesh proxy object for the building itself, called
"BedfordCourtProxy"
- in leam.max, the bool'd building object "BedfordCourt" is
Xref'd in but uses its proxy to avoid crazy transform weirdness resulting
from the bools (reset transform doesn't work on bools)
- then I used the 'Xref Objects' window to add the raw sub-object bools
"crukFramesNORTH" & "crukFramesEAST".Max spots that they're children of
"BedfordCourt" in the external scene, and offers to make the Xrefs
children of the building Xref.I
accept and it works - no transform problems for the child objects, so they
don't need proxies.
Remembered that the 'draw to
reflections' scenic flag, when set false, also causes the child objects to be
skipped in the reflection draw.This
is good.Same goes for 'draw to rain
occlusion' and 'draw to shadows'.
#revision
1766
#revision 1767
The following files now live in Graphics rather than Graphics/Final
(which I'm trying to get rid of):
leam.x
leam.nwf
scene.x
TODO: probably best to move them into
Graphics\Scenery instead.<-DONE(9th)
TODO: Change CCullPlaneManager
to use the new view frustum.
#revision
1768
Had a problem with the
window-frame sub-objects of the BC Xref - when their 'name' entries were
parsed in CLandscape::ReadProperty, the frame returned by FindFrame was a
stub frame rather than the one I wanted.That's why these sub-objects' cull-planes were null.
I've now improved the hierarchy pruning so that nodes with no mesh and no
child, that aren't CMeshFiles, are pruned out.That fixed the problem, and has stripped
out 156 stub nodes, kewl!
Bedford Court is progressing
nicely (by my standards at least; a real modeller would say I'm taking
forever with it).
I might release a build tomorrow night.
The increased building detail is really showing-up imprecisions in the
shadows.Nothing worrying - no
intrinsic problems; I just need to consider rendering them at a higher res
and using better (more expensive) softening :/
5-nov-2008
2,75
TOFIX: cpBedfordWest (west side
of Bedford Street) is culling the north sub-objects of Bedford Court.
What's supposed to prevent that again?
30-oct-2008
3,5
Continued modelling Bedford
Court.I'm getting a good grasp of the
workflow now, and the building is starting to come to life.
It now has two floors; all the windows and arches are cut into the shop and
the upstairs bit (so you can see in), and the basic blue window frames are
in.
This evening, instanced
modifiers and Linked Xform modifiers are my favourite things.
27-oct-2008
3,5
MAX: Perspective view: ctrl+alt
+ middle-drag forward & backwards, for sensible camera movements!!
MAX: Boolean
modifier-stack-entries can't be dragged up or down like other
modifiers.
This means that once an object is referenced, bools added to the top of its
modifier stack don't appear on top of the references.
In other words, each time you add a bool on top of something, it becomes a
different object, and any references to it only reference one of the bool
operands.
So bool objects can't safely be referenced into other
bool objects.
MAX: Holy moley, modifiers can
be copied and "pasted instanced" (creates a two-way link between
the two instances of the modifier).Instanced modifiers show in italics.
MAX: Hmm, the problem I'm
finding now is simply that there's no Boolean modifier type.Everything would be perfect if Max had
Boolean modifiers instead of Boolean objects.
Max: Remembered about the fancy
primitives such as:
- windows
- walls
- stairs
- fences
- trees, some really nice ones
MAX: Lights and CullPlanes are
going to be kept in leam.x, not in the buildings' sub-scenes.
So there's no changes needed in the deployment scripts.
MAX: All Xref'd nodes lose their
modifiers, and in the case of lights and cull planes, they sort of lose their
type as well.
That's why lights and cullplanes can't be set up in the Xref'd building
sub-scenes.Doesn't bother me though.
#revision
~1703
Separated Bedford Court off into
its own Max file (graphics\objects\buildings\BedfordCourt.max)
Xref'd it into leam.x, and it worked!So now I'm finally at the stage where it's safe to start modelling
buildings!
#1
SVN, trying to commit the
project folder since moving to new PC:
"Commande: Livrer
Erreur: Échec de la propagation (commit), détails :
Erreur: Impossible d'ouvrir une session ra_local pour l'URL
Erreur: Le dépôt 'file:///C:' n'a pu être ouvert
Erreur: Impossible d'ouvrir le fichier '\C:\format': Syntaxe du nom de
fichier, de
Erreur: répertoire ou de volume incorrecte."
This seems to only happen when there's
modifications in more than one sub-folder.
<-FIXED (#2)
Visual Studio:
find-&-replace bug:
find: "_cullPlane."
replace with "pCullPlane->"
match case, match whole word
replaces "_cullPlane " (space instead of dot) with
"pCullPlane->"
#2
SVN: Managed to fix my tangled
working copy (project folder), so that I can now commit from the top
level.
It had become tangled because I had copied it in its entirety (including
the SVN gubbins) from the old PC.
Wouldn't let me commit from the top level (see #1).
Fixed it by doing this:
- check everything in
- delete all SVN files from normal working copy
- make a new clean checkout in a separate location
- copy all files from clean checkout into the normal working copy
#revision
1721, 1722
Started going down the route of
calculating cull-plane exclusions at load time rather than deployment time
(thought I needed to, for Xrefs).Turned out I had just broken a hierarchy link so the north cull-plane
of BC wasn't a child any more.
Now fixed.In case the load-time
code is ever needed, it's in stuff.cpp.
MAX: To stop the flickering grey
soot over all the objects:
untick Object properties \ Vertex channel display
(vertex colour)
NOTE: need to turn this on when not using a DX
shader material though.
#revision
~1739
It took quite a lot of hours,
but I've now successfully booled-out a bunch of windows at Bedford Court, and
used references of the same shapes to build the window frames, and the
decorative brick surrounds on the texture patchwork.The frames and surrounds are working neatly
in Max; yet to export them to the game.
Extrude and Shell modifiers are my new best friends.
If the shapes need shifting or scaling, the best way will be to use Xform
modifiers directly above each one.This'll update the bools, the frames and the surrounds, on multiple
walls, as if by magic.
I didn't know if this 'tower of bools and modifiers' approach to modelling
the buildings was going to work or not (or if Max would be sturdy enough to
let me do it), but it is really working well.And I find modelling very relaxing.
I'm mid-way through phasing-out
the 'Graphics\Final' folder (to use 'Graphics' instead).Decided not to use 'obj' and 'tex' folders
for each sub-scene; meshes and textures now live together, along with their
PSDs.
- Moved Leam.x to Graphics
- Moved Lamppost and BC sub-scenes to Graphics\Scenery..
- Most textures are still in Final
25-oct-2008
8,91667
BT building (north cull
plane):
- broken in 21.2
- also tested 17.6 and it's broken there too
So it's always been broken.<-FIXED (#1)
#2
Visual Studio: added the
executable path:
$(DXSDK_DIR)Utilities\bin\x86
so that 'fxc' (shader compiler) is found
#1
#revision 1689
Found the cause of my
disappearing BT building.
In CLandscape::ReadProperty, when reading each property such as
cullPlaneExclusions, I hadn't been asserting that the 'current scenic frame'
pointer was non-null.It always was null, because
CLandscape::FindFrames was getting called later than
CWorldParser::Parse.
Also remembered that CWorldParser::Parse is called twice, to perform two
different passes of the world loading.
TODO: change this into a single pass - less dangerous and confusing.
#revision
1690
Re-added a cull plane on the
south side of Regent Street.Had
deleted it at some point in the past because of the problem fixed in
#1.
Checked that the cull plane works (hides the buildings on Augusta Place).
Re #2: also copied fxc into
C:\windows because it was the simplest way of getting ShaderBuild.exe to work
without hardcoding a path.
#3
Building all shaders on the new
machine/DXSDK, I've started getting this error:
"error X3025: global variables are implicitly
constant, enable compatibility mode to allow modification"
But strangely the shaders still seem to be
working exactly as they should (I suppose because compatibility mode must've
been enabled by default in previous versions of fxc?)
#revision 1691
Fixed #3 in h_Projector.fx-<-SEE #4
#revision 1693
Fixed #3 in h_GroundPOM.fx
#revision 1694
Fixed this in Ground.fx:
"c:\Noctambule\Source\HLSL\Ground.fx(581,4):
error X3017: 'PSReadGroundTopology': cannot convert from 'float' to 'const
float'"
fCurrHeight = tex2Dgrad( normalsHeightSamplerIn, vTexCurrentOffset, dx, dy
).POM_HEIGHT_CHANNEL;
"h_GroundPOM.fx(156,17): warning X4121:
gradient-based operations must be moved out of flow control to prevent
divergence. Performance may improve by using a non-gradient
operation"
I've got no idea why the DX sample
ParallaxOcclusionMapping.fx doesn't give this warning - it's the same code
(tex2Dgrad inside a 'while').What am
I missing?
Would be interesting to do a diff between the latest version of that sample
file and the version I ported from (except, I ported from the ATI sample not
the DX one).
Wowza - there are actually NO
Google results for "warning X4121" (except maybe this one ;)
Had a look at the DX10 samples.
#revision 1696
HDRLighting.fx, HDR.cpp:
Appended "_Technique" to the technique names to prevent name
conflicts with the PS functions:
"c:\Noctambule\Source\HLSL\HDRLighting.fx(807,11):
error X3003: redefinition of 'Bloom'"
#revision 1697
increased water refraction on
the ground (0.03 -> 0.1)
Removed the 'Website' folder
from the source project (it contained the old website).
Tried copying all the FXOs from
v21.2 into my working copy's Source/Master folder.
This appears to reproduce Carl Kenner's bug, or
something similar!!
Because I've renamed the techniques in
HDRLighting.fx, HDR.cpp will be silently failing to set any techniques.The question is - why would this be
happening on someone's machine in v21.2 (where the technique names are
correct) ???
I can almost imagine it's something to do with DirectX versions.Maybe some versions can make use of
techniques with bad names and some can't.
#4
#revision 1699
Caused myself a silly shadow bug
in revision 1691, by removing a #include that I thought wasn't needed.Although none of the header's FUNCTIONS
were being used, one of its DEFINES was.And of course, FXC didn't give me any warning that the define was
missing, even though I used #if rather than #ifdef.Apparently C/C++ compilers don't give any
warning in this situation either - seems wrong to me! >:(
The lesson is: when tidying code, be hellish wary of removing
#includes.Fixed in revision 1699
I've removed all the anaglyph
ghost reduction variant shaders.If I
ever re-add the ghost reduction, I'll use uniform variables instead.
The plan for tomorrow is to get
started on the SCENERY PATCHWORKS, ie. the system that allows the building
textures to be assembled in Max as sorta collages - and if need be, rendered
by the game viewpoint-dependently for infinite resolution, phwoar.That's what I'm already doing with the
ground textures, and by jingo does it make things easy (and allows me to use
parallax occlusion mapping everywhere).
There's a million other things I should be doing instead, so why this?Because the placeholder scenery textures
are grinding-down my morale.They make
the game look stupid. Tomorrow, finally, I'll start doing something about it.
GRR, Windows just restarted my
machine (to "configure updates") while I was in the middle of
typing.
Totally out of line, that.I'LL
decide when to turn off my computer, thanks.
TODO: release v21.3 (it's ready
to package)
22-oct-2008
1,666
Replaced a load of placeholder
lampposts with Xref'd wobbly ones.They all worked!
Just got a bit of disappearing-building
weirdness at the north side of the BT building though.<-FIXED (25th, #1)
Found that instances of
references seem to work just fine for the likes of these lampposts (unless that's what's causing the BT building to
disappear?)TODO: investigate<-FIXED (25th, #1)
21-oct-2008
3,666
MAX: Xrefs no longer need to be
top-level; they can be placed in the hierarchy like any other object.
Deploy.ms now writes a 'ParentName' entry into each 'FrameMeshName' block
(or writes "<noparent>" if the Xref is root-level).
Added a CMeshFrame::FindFrame
that takes a CRC rather than a name.
Added CMeshFrame::InsertFrame,
which is now used by CMeshFrame::AutoInsertFrame
Added CMeshFrame::fixupParentCRC
TODO: make pruning stricter
& simpler.Chuck out anything with
zero radius.
Finally got manual insertion of
Xrefs working.Tomorrow I'll give this
a workout by placing loads of wobbly lampposts.
19-oct-2008
6,083
TODO: investigate visibility
testing of likes of lightMarkerSphere_pointLight06
ie. should that object even be trying to draw?<-probably pruned-away now; see #1 below
CMeshFrame: in the course of
some debugging, I added a temp test method 'IsLamppost'.Found that this could only worked properly
when called from within CAnimMesh rather than CMeshFrame.And I was using the 'override'
keyword.No idea what was going on
there.Rebuild-all didn't help.
NOTE: Drawing debug spheres in
the shadow depth render is currently a bad idea!That was really adding to the confusion
this morning.
Wrap any debug draw in:
if(
CModeEnvironment::s_pCurrentRenderData->renderCategory ==
ERENDERCATEGORY_MAIN )
#revision
1683
#revision 1684
CCullPlaneUser now uses a
CBoundingBox member ('bounds') instead of minPos, maxPos & centre.
#revision
1685
Fixed the handling of dynamic
bounds for reactive scenics.This
fixes the disappearing shadows on the new lamppost I added the other day.
#1
Landscape hierarchy pruning is
now done after auto-insertion
of Xrefs (object instances such as lampposts and cars).
Right then - recursive Xrefs
with manual placement in the hierarchy - that's what I need now.
- I'll change Deploy.ms to generate a '<worldname>_scene.x' file
(like the current scene.x), for the max file that it's run on.
- FrameMeshName entries in these '_scene.x' files will now specify which
'_scene.x' file to include as an instance.
- For the manual placement in the heirarchy, FrameMeshName entries will
simply include the name of the scenic that is their immediate parent (need to
throw up an error if the parent isn't a scenic).
TODO: finish altering
Deploy.ms.Update the template at the
top of LoadSceneFromX.cpp, so that it reads in the parent name.
15-oct-2008
0
Downloaded and installed the
Vuzix (VR920) SDK from here:
http://www.vuzix.com/support/downloads_drivers.html
Put the VR920 SDK into
SVN.
Im pleased that it's every bit as user-friendly as the eMagin SDK.The samples build & run straight out of
the box.This should be an easy
headset to support :)
TODO: See comments about
synchronisation in the MatricesQueryGPU sample.
Could this be useful for the Z800??
12-oct-2008
7
I don't know why this devlog is
such a big file now (over half a meg).I'm going to have to start a new one (again).
MAX: SVN-'restored' the file
stdplugs/cmbtex.dlt which was missing.
No idea what it is or what it does, but I (presumably) had it on the old
machine so let's have it on this one too.
SVN: Gave the project folder a
cleanup after committing all the sub-folders individually.So far it seems to be
behaving again (can commit the top-level project folder again).
<- nah, still broken
#revision
1669
WOWvx: 'Set offset' now works
(previously there was a paste-o bug causing this to be controlled by 'set
factor').
#revision
1670
#revision 1671
#revision 1673
I've hidden (and might decide to
remove) the option to specify a field of view directly (auto-fov is now
forced on).
Auto-fov got broken by the recent frustum changes.There are too many if's and but's to do with
the way an arbitrary FOV setting would relate to stereo and
headtracking.And I've never wanted to
turn auto-fov off anyway, except for WOWvx.
My advice to players who want a bigger FOV is "buy a bigger
monitor" or "sit closer to the screen" ;P
The WOWvx default-override profile now produces a sensible FOV by setting a
fake viewing distance of 70 whereas the real distance would be about
300.This will break if OptiTrack
headtracking is used with it (the headtracking will measure the real viewing distance and update
the view accordingly).
Previous vertical half-fov used in the WOWvx profile was 33°.
#revision
1672
Measured the virtual screen of
my Z800, using a tape measure.This is
with each eyepiece shifted two notches out from its innermost position:
- screen width: 81 cm
- viewing distance: 144 cm
These settings are working well and are now in the Z800 default-override
profile.
#revision
1674
Removed the following example
profile from the install; it was duplicating the WOWvx default-override
profile:
Example_3DDisplay_Philips_WOWvx_42inch.txt
#revision
1675
The following example profile no
longer specifies a frameRT value (because frameRT is now automatically set to
an optimal value in over-under-gap mode):
Example_Stereoscopy_Another_EYE_2000_syncDoubled.txt
#revision
1676
Controls: Reduced the default
mouse turn & pitch speed from 0.1 to 0.055.
Various people had said the old defaults were too fast.Thinking about it, the reason the high
sensitivity felt right to me would be that I disable Windows' 'enhance
pointer precision' thing (so I'm used to making smaller movements).
Interpupillary distance now
defaults to 6.4 cm, which is apparently just right for a typical European
woman (ie. errs on the side of a weaker effect rather than discomfort).I've also seen this number used elsewhere
as a typical IPD.
See info:
http://en.wikipedia.org/wiki/Inter-pupillary_distance
See also comment #1 from yesterday.
#revision
1678
Found that shadows had become
blocky when using 3DVisor.Investigated and found it was because
Cfrustum::SetupViewFrustumWithOffsetViewpoint actually wanted to take in a
width and height for the near-clip end of the frustum, not the screen width
& height,
Now fixed.I had hoped that this
also would fix the cutting-out of shadows at the edge of the screen when
using window headtracking, but it didn't.
As a result of the fix above,
shadows and objects can sometimes be seen cutting-out at the edges of the
screen in stereo modes or when using window headtracking.It's a bit distracting, so I expect I'll
fix it fairly soon.
Checked that this bug was present on v21.1 - reproduced it by setting the
screen width small........does that make sense??
MAX: Hah! Remembered what
stdplugs/cmbtex.dlt is - it's The File That Stops Max Loading (on this
PC).
Deleted it again.
11-oct-2008
3
#1
(below) Carl Kenner rightly
pointed out that my HMD stereo was still wrong in v21.0 / v21.1:
I had been using the assumption that an HMD places a display directly in
front of each eye.If this were true,
it would mean that 2D images on an HMD would appear infinitely distant, which
they don't.On my Z800 I get the
impression that the 'screen' is say 120cm away.
I think it would be bad, uncomfortable HMD design if 2D images appeared
infinitely distant, because it would force the viewer to the limit of their
eyes' range of motion.I get the
impression that when eyes are totally relaxed, they're not parallel; this
explains the faulty 'measurement' I got for interpupillary distance a while
back (a stare-up-close-to-the-screen test gave ~5.35cm instead of
~6.4cm).Still, it is useful to get
that 'relaxed' measurement for reference.....
I fixed the HMD stereo fault
described above and it made a big difference, which is great.There's a full range of depth now.
I also re-tested 6DOF TrackIR
headtracking in combination with 3DVisor stereo.
It's like the beginnings of a holodeck - I can creep round in a very small
area of the bedroom, peeking around the edges of virtual objects, ducking
behind virtual walls, pacing around on a piece of virtual pavement - it's all
life-sized and properly placed in my field of view.
The weak links are the FOV and angular range of the TrackIR / TrackClip
PRO.All I'd need is positional tracking around the whole room
(angular can come from the Z800), and I'd have a sort of holodeck - it would
be awesome!
So the question is: what's the easiest way to track the 3D position of an
object that's moving and rotating freely within the bounds of a room?
I'll release v21.2 tomorrow.
Found a French (only)
dictionary:
http://www.cnrtl.fr/definition/mot
Knackered the Windows XP on what
was my master PC.Spent the past few
days setting-up camp on the new PC instead (all done now, apart from VS2003
which I might not bother with - was only used for maintaining the older web
pages).
Before that, I was tied-up with some time-critical stuff at work.
Big thanks to Brian from Oz for
helping to debug a TrackIR compatibility problem.Details are now in the release notes.
The release log also links to the required versions of the NaturalPoint
installs, hosted on my site, so hopefully the game will be future-proof now
as far as headtracking's concerned (the required eMagin dll is already
included in the install).
v21.1 was supposed to fix the
sound initialisation on my Vista 64 machine at work, but strangely it
didn't.
The bug I found was that UtilGetTempWideString was being used in two places
at once - I'm amazed sound loading ever worked.
31-août-2008
9
Removed TestPointVisibility
because it was OOD.
Spent the day weeding-out bugs
to do with shadows and culling using the new view frustum.
It's still not perfect - the window-style headtracking can cause gaps in
the shadows at the edge of the screen.
But I can't afford to spend any more time fixing it.
NOTE: the 'head-mounted display'
option assumes that each eye has its own screen in front of it (binocular
display).TODO?: separate option to
indicate that?
V21 BODGE: Since auto-fov is
currently forced on unless an HMD is used, I've improved the FOV in the WOWvx
default overrive profile by removing its value for realWorld/distanceToScreen
Inspected stereo correctness of
falling rain.It looks wrong sometimes
in cross-eyed mode, but I think that's just because the interpupillary
distance is doubled.In anaglyph mode
it looks right.
It seems to move with the viewpoint though (not usually noticeable becuase
it's falling so fast).
#revision
1619
CNoctambuleApp::SetCameraEye:
Added null checks to prevent master-only first-frame crash on v21.0.todo: investigate
Headtrack calibration mode is
now enabled in master builds.Doesn't
draw in stereo [yet], but other than that it works.
Started to realise that making
the FFSM shadows work with my new view frustum was going to be more
complicated than I'd thought.I was
getting close to something that looked right, but there were definitely gaps
and guesswork in the maths, which it could have taken forever to clear
up.
So I've decided to change CFrustum so that it's always a regular
frustum.In the case of the new
shadowing frustum, it'll be the regular frustum that *contains* the irregular
view frustum.
In this way, the FFSM code stays practically the same as it was before -
still using a view direction and two half-fov angles, rather than a set of
completely unmatching faces.
Revision 1605 is the point I got
to before turning back.
#revision
1606
Reverted:
Projector.cpp to revision 1569
Projector.h to revision 1497
#revision
1607
Changed Projector.cpp to use
g_viewInfo.cameraSpaceViewFrustum (TODO RENAME), instead of all the
g_viewInfo.mainView* stuff.
Picked up a couple more 99p
domain names from 123-reg.co.uk:
s-3d.info
stereo3d.info
s-3d.org was tempting, but nah, I don't need it.<-couldn't resist
28-août-2008
5,16667
Got the shadows 90% working with
an offset viewpoint.Just a little
join-up problem remaining - probably to do with the projection matrix
(SetupResBiasForFrustumPlanes).
It's worth all the hassle to
cater for this unusual view frustum though - I still can't get over how
comfortable and weighty the stereo is now (v21).
27-août-2008
1,43333
#revision
1597
Website: Added the WOWvx-related
source code back onto the FAQ.
#revision
1598
Setup: Added the following code
files back into the installer:
-WOWvx.h
-WOWvx.cpp
-HLSL\WOWvx.fx
-HLSL\h_WOWvx.fx
-HLSL\Interlace.fx
-HLSL\Chequer.fx
-HLSL\StereoscopyMirror.fx
#revision
1599
Setup: Added the 3DVisor source
files to the installer.The eMagin SDK
has been totally public for some time now.
Downloaded the SDK again, from the public route this time; couldn't see any
differences in the docs to do with confidentiality details.They're still marked confidential, but they
can't be if they're publicly linked-to on the eMagin site.
Earlier on I got a blue-screen
crash when changing my windows theme (just trying to switch to better colours
like I always do).Promptly backed-up
all my source to a USB stick.
Presumably related to that crash some way, Windows is now making *sounds*
whenever things happen (eg. breakpoints) :/Make it stop!
#revision
1600
Fixed the main bug I was seeing
the shadows since changing to the new view frustum (far face had gaps all
round it).The bug was in
SetupViewFrustumWithOffsetViewpoint.
So everthing's rolling again, phew.I'm looking forward to version 21.
TODO: get the shadows handling
an offset viewpoint<done(31st),
then a stereo frustum.
26-août-2008
0
Tied-up with work :(
25-août-2008
8,18333
#revision
1583
Website: Had to remove
WOWvx-related source code from the FAQ (sorry).
#revision
1584
Setup: Removed the following
code files from the installer:
-WOWvx.h
-WOWvx.cpp
-HLSL\WOWvx.fx
-HLSL\h_WOWvx.fx
-HLSL\Interlace.fx
-HLSL\Chequer.fx
-HLSL\StereoscopyMirror.fx
#revision
1587
Added a frustum class CFrustum
(Frustum.cpp & h)
#revision
1587
g_viewInfo.GetCentralViewMatrix
now returns the main camera's central view matrix.Previously it was returning the final view
matrix.I think that was part of the
problem with the stereo mist (see CMist::Prep)
TODO: needs to be renamed if it deals with just the main camera.
#revision
1587
Added
g_viewInfo.cameraSpaceViewFrustum
NOTE:
- D3DXPlaneFromPoints creates a normalised plane.
- D3DXPlaneFromPoints creates a plane with its normal pointing out of the
side on which the points appear clockwise.
TODO: Test falling rain (uses
TestSphereVisibility with vpRelativePositionIn=true)
Nice, never seen this one
before:
"Edit and Continue : error 1013 : Debugger ran
out of memory while applying code changes"
Currently half-way through
fixing the shadows to work with the new view frustum (for headtracking &
stereo).
24-août-2008
11,0833
Found that window-style
headtracking is at its most effective when mouse pitch is switched off.TODO: put the mouse pitch option on the
headtracking menu?
Update: there was also a projection bug that made pitch look wrong in
window headtracking mode; now fixed.
Added function
MatrixRemoveOrientationAndScale
#revision
1577
HMD-style headtracking is now
6DOF when using TrackIR.
#revision
1577
Website: Removed any mention of
where I work.
Prevented a crash on exit while
headtracking is in use.
Added g_game.flags.shuttingDown for this.
#revision
1580
Cross-eyed default override
profile no longer sets a large interpupillary distance.
Interpupillary distance should no longer be used as a means of customising
the stereoscopy - it should be the exact distance between the player's
pupils.
#revision
1580
NOTE: the rain mist is currently
using an infinitely-far stereo depth.It's going to have to stay that way till I get the chance to change it
over to use a sphere mesh.Now that
the projection matrix is non-standard, the method I had for drawing it in
stereo before (which was broken anyway) can't be used.
It doesn't look especially wrong being infinitely far away (and looks
better than it did), but it would be much nicer if it had proper stereo
parallax.
I don't think anyone's going to be too concerned about it except me.There are more important things to fix.
#revision
1580
Removed the stereo convergence
setting.I might add a suitably-named replacement for this later.
#revision
1581
Interpupillary distance now
defaults to 5.5cm instead of 7cm.I've
measured and tested this; it's better.
#revision
1581
Tested TrackIR headtracking + an
HMD; this is now working (6DOF).
Even tried using anaglyph for the stereo - that works properly as well.
#revision
1581
The 3DVisor default override
profile no longer overrides:
- interpupillaryDistance
- displayWidth
- distanceToScreen
It now sets an explicit fov.
Distance to screen should no longer be used as a means of customising the
stereoscopy - it should be the exact distance from the player's
point-between-eyes to the monitor (if there is one).
CHeadTracker::ResetTransform no
longer resets the yaw in Z800 mode.The function was only called when exiting pause, and I've got no idea
why I would want to reset the yaw at that point; seemed sily.
TODO (low priority) : make the
Z800 profile independent of the headtracking method (always loaded if a Z800
is detected, even when the headtracking method is set to OptiTrack or
force-none.
#revision
1582
Fixed the bug that was stopping
the Z800's keep-alive signals being sent.
In CHeadTracker::Update, it was checking the frame number to know when to
send the message, but the frame number is incremented twice between each
update because of the frame-sequential stereo.
Now fires every ten seconds when running at 60fps.
This does mean I have to remember not to leave the game running in the
background for a long period of time.....
NB - the keep-alive message also brings the headset
out of standby mode.
23-août-2008
4,8
CCamera::CalculateProjection now
calculates projection pre-calcs before building the projection matrix.
Previously it was pulling some of the pre-calcs out of the projection
matrix, which is nifty as long as the projection matrix is standard.But I can't rely on the projection matrix
being standard in any way nowadays.
A double-whammy of Win
today.
1. Worked out the correct transformations for the window-style
headtracking; got that all working the way it should be.
2. Realised that those same transformations are exactly what's needed for
geometrically-correct stereo projection on a fixed monitor - instead of converging the views!
On a fixed monitor:
Stereo convergence =
WRONG; it's a lazy approximation of what's actually needed.
Offset projection =
RIGHT
The results are wonderful.I've been using real-world measurements for
stuff like screen dimensions, interpupillary distance, etc. right from the
start, but until now they've never quite added up right.Now, they create a stereo scene that looks
and feels perfectly life-size.It's
got all the weight and depth as if it's really there.Can't wait to see this on a 3D monitor.
TODO: shadows need to know about
the new frustum.Might be a good
opportunity to build a unioned stereo frustum.That will remove all the projector depth
draws from the second eye, at the cost of some shadow res.
TODO: reflect the shadows.
TODO: deal with anything else that uses the g_viewInfo FOV data......
TODO: take head tilt into
account in the stereo<-DONE (24th)
22-août-2008
3,5
#version
20.6
#revision 1565
Built version 20.6 (same as 20.4
but with no source code)
#revision
1566
The new OptiTrack tracking
produces noticeably cleaner movements than the old version, as well as
achieving its results through far less processing.Mathematicians rock!
So I've chucked out the old functions:
COptiTrack::InterpretObjects (old version)
COptiTrack::FindBestZPositionRecursive
and let's never speak of them again.
COptiTrack::TestZPosition is still used; I pass it the single Z position
calculated from the Alter equations, and it gives me back the fore & up
vec.
#revision
1568
Removed unused option g_game.options.headTracking.smoothing.
Removed its slider from the head-tracking
menu.
Added 'Head-mounted display' check to the OptiTrack menu (this toggles
between HMD/window head-tracking styles)
Reduced default value for OptiTrack/smoothingRange (0.1 -> 0.05)
Found the source of the faulty
pitching tilt in the window-style headtracking.Will concentrate on improving window style
tomorrow (see #error here).
It's going to be really amazing playing this game with TrackIR and a 3D
screen together.Even ghosty old
anaglyph becomes thoroughly convincing when combined with the window-style
headtracking.
21-août-2008
3,83333
#revision
1563
OptiTrack (TrackIR) optical
head-tracking:
Successfully replaced my binary-search-based point interpretation with a
version that uses 'weak-perspective projection'as described in the paper "3D Pose
from 3 Corresponding Points under Weak-Perspective Projection" by T.D.
Alter:
C:\noctambule\articles\headtracking\AIM-1378.pdf
I ported the code from crim3's
script that uses this same method - big thanks to him for posting that on
MTBS3D.com:
http://www.mtbs3d.com/phpBB/viewtopic.php?t=1643
(C:\Installs\Crim3HeadTracking\wii_alterpose_trackir\wii_alterpose_trackir.PIE.txt)
This is also the method used by Free-Track.I tried getting the Free-Track source code
using TortoiseSVN but didn't manage......
20-août-2008
3
(below) Inspired by this thread,
I decided it was time to finish-off my TrackIR headtracking support.
Found that the TrackIR
headtracking is completely broken nowadays - oops...
#revision 1559
Headtrack calibration meshes are
drawing again.Had to pass
MESHRENDERFLAG_DONTSETOBJECTMATRIX.
Should that be a default flag??
TODO: draw menus at screen depth
in cross-eyed stereo mode.
Got the TrackIR headtracking
back into the state it should have been in.
#version
20.4
#revision 1560
Built version 20.4 (English,
fixed TrackIR)
#version
20.5
#revision 1561
Released version 20.5 (fixed
TrackIR)
Website: bought another 100MB of
space
19-août-2008
4,5
Installed 64-bit nvidia drivers
on the slave.
Tested v20.1 on Vista 64.Can't get it to misbehave in any way
:/
On my machine at work, it fails to find shoot.wav, and can crash when it
loses focus (while loading, I think).
TODO: I'm going to have to debug
the game on my work machine to find out what's causing the problems there.
I'm also finding on Vista 64 on
the slave that the two monitors don't need to be set to the same refresh rate
(in nvidia control panel) for the multihead modes to work.
#1
Vista 64: Lampposts and
drainpipes are showing uninitialised vertex colours.
#revision 1550
Added dual-monitor stereo mirror
options, and StereoscopyMirror.fx.
Mirrored stereo is a surprisingly good (and
economical) viewing method!
Now exporting leam.x as a compressed binary X file.1.7 megs instead of 9.6.
And it actually works!For some
reason I was expecting it all to go wrong, but it works.
Speeds up loading and dual-monitor mode changes nicely.
#revision 1552
Re #1: Added VertexPaint
modifiers to the objects I'd seen coming out black on Vista 64.
Grrr, the compressed binary leam.x makes the install bigger than it was with the text
version!!
#revision 1557
Re-constructed the English
installer.
#version
20.2 en
#revision 1555
Built version 20.2 en.
#version
20.3
Built version 20.3 (English)
18-août-2008
Installed Vista 64 on the slave
again.
17-août-2008
8,666
#revision
1542
Realised I do want an
eye-swapped iZ3D mode.Doesn't swap
the front & back, just the left & right images from which the front
& back are formed.
This is useful if the player is using flipped glasses, or if I somehow get
the eyes the wrong way round on the first attempt (certainly should be
correct), or if the format flips in the future for some crazy reason.
Added shader effect iZ3D.fx (form iZ3D front and back
images from a left and right image)
This is an asm->HLSL port of the pixel shader from the reference code
(HLSL so I can see what's going on and connect it up more easily).
iZ3D.fx is confidential and therefore excluded from the released source
code (sorry!)
Double-checked that iZ3D.fxo
doesn't reveal any comment strings
COptions::ApplyStereoscopy: For
the benefit of per-value override profiles, had to change it so that the
likes of g_game.options.stereoscopy.iZ3D get set even when the mode is 'denatured' (ie. inactive until
the device is suitable).
#revision
1545
Moved the iZ3D modes further
into the list (just before checkerboard), in accordance with the rule about
menu readability (in fullscreen mode).
Depending on feedback, I might want to force the menus to screen-depth for
iZ3D, in which case I will move the iZ3D mode back to before anaglyph.
<-d'oh!Just remembered that iZ3D
mode, even in fullscreen, doesn't apply automatically.The menu is therefore 100% easy-to-read
when you're cycling through those modes.Now moved it to before anaglyph.
#revision
1546
Added column-sequential stereo
mode (now ready to use).
Borrowed Interlace.fx for
this.
Stereoscopy: Confirmed that
canFreezePauseBackground and canUseEyeStyleMotionBlur must both be set false
for dual-monitor and iZ3D stereo modes.
Stereoscopy: Moved the drawing
of the Z-buffer mask into CNoctambuleApp::DrawStereoscopyZBufferMask
#revision 1547
#revision 1548
Started trying to improve the
checkerboard mode to make it more efficient.This would involve drawing the Z-buffer mask as early as
possible.
Quickly gave up for several reasons:
- realised this wouldn't be compatible with motion blur;
- didn't seem to be getting any speed increase (??) when I moved the mask draw right back before the scenery
draws - even though the mask was clearly doing its job there;
- shadows and motion blur were very broken.Time is too short to spend it fixing unnecessary problems like
that.
Revision 1547 is the point I got to before giving up.
Revision 1548 puts it back to the old way.The code is slightly neater now, which is nice.
Anaglyph mode now supports
yellow filters and magenta filters.
TODO: tomorrow I'm going to
quickly add 'mirroring' options to the dual-monitor stereo mode, because the
mirrored viewing method seems quite popular.I'll borrow a screen-sized LDR rendertarget and just blat it onto the
backbuffer horizontally flipped, job done.There's no nicer easy way of flipping an entire frame (I would need to
manually flip the menus, the rain, headtrack calibration....yeugh).
<-done(19th)
16-août-2008
10,25
#revision
1529
Added function
g_game.IsDeviceMultihead
Indicates whether or not the current D3D device was created as a multihead
device.
TOFIX?: the HDR middle grey
value seems sligthly different (in effect, not the number) between
dual-monitor stereo mode and mono mode (?)
->probably just due to the large difference in framerate in the pause
menus between those two stereo modes.
#revision
1530
Added
CMenuItem::flags.flagOptionOverrideOnChange (usually true; set false on the
fullscreen check as a temp workaround for the crash seen when starting in
fullscreen mode on Vista 64, Quadro)
The second monitor is now
cleared to black, the minimum required number of times, when not in use
(rather than continuing to swap through its last few frames).
See CNotambuleApp::flags.clearSecondaryLDRBackbufferOnce
...of course, duh, I could have just hidden the second monitor's fullscreen
window :/
Shadows: TOFIX: the +Z face
doesn't seem to be getting the full benefit of the adaptive frustum stuff -
it's blocky even when the wall is right up close.
<-see #2
#revision
1535
DXUT.h: defined
DXUT_MAX_SUPPORTED_ADAPTERS, the maximum number of grouped adapters that the
app can cope with.If there are more
adapters than this in the group, we display an error message and close the
app (the player will have to disable the excess monitors in order to run the
game).
Currently set to 16.
This is now used as the number of elements for DXUTDeviceSettings::pp.
NOTE: D3DCAPS9::NumberOfAdaptersInGroup shows as 1 in span mode.
#revision
1535
Removed g_game.IsSecondMonitorUsable (made redundant by g_game.IsDeviceMultihead)
#revision
1535
Added function
DXUTInternalPropagatePresentParameters
#revision
1537
ESTEREOSCOPYMODE_DUAL_MONITOR_1/2
now behave like ESTEREOSCOPYMODE_NONE while the device is not multihead.
#revision
1538
Added
COptions::stereoscopy::canDisplayCrosshair.This is now set true when ESTEREOSCOPYMODE_DUAL_MONITOR_1/2 are
mimicking ESTEREOSCOPYMODE_NONE.
#revision
1538
Fixed the problem I was getting
where the window was using DXUT default sizes on change of device; now uses
correct size.
#revision
1539
Added
CPauseMenuTree::OnSetStereoscopyMode, called from
COptions::ApplyStereoscopy.
Removed redundant CPauseMenuTree::MenuItemCallback_StereoscopyMode.
#revision
1539
Chugmaster debug menu option is
now disabled in master builds.
#revision
1540
With multihead disabled in the
video driver app, I was finding that full-screen alt-tabs were again causing
a device change.Solved this as
follows:
DXUTRender3DEnvironment: // PP(16.8.8): never favour a new
device (it's nothing but trouble) favourNewDevice = false;
#2
Re #1 (shadows looking blocky on
PZ face even when facing a close wall) :
Remembered that the collision side of the FFSM adaptive frustum code only
controls the near distance of
the frustum.It would be unsafe to use
the collision info to control the far distance, unless perhaps we knew that a
CullPlane was covering the screen??
TODO?
...The other thing that might
well be worth doing is reducing lights' shadow casting
range independently of their light casting range.
TODO!(see
CProjector::UpdateViewFrustumExtents)
Bought an extra gig of hosting
bandwidth, because I'd exceeded my 3 gigs.
I'm quite baffled by the amount of bandwidth apprently being used by my
site.Are there really as many as 130
people downloading my demo each month?? (130 x 24 MB = 3.12 GB)
Re #1 yesterday:
Re-tested v19.0; tested more carefully this time and found it behaves
exactly like the latest code.
test:
- set monitors to 2048*768 horizontal span mode
- setfullScreenXRes:2048, fullScreenYRes:768
- run game and alt-enter into fullscreen mode.Ensure span mode is working.
- alt-tab back to driver app.Switch
to vertical span mode (1024*1536)
- alt-tab back to fullscreen game.Mad flickering of black window-type-thing followed by a crash or a
hang (stack overflow).
Did the same test on v17.6 (17
was the first build after revision 1287, where I reckoned I'd got this all
sorted).
17.6 also does the same the the latest code.So this case has never worked.
Finally, tried the same test
with v16.1 (WOWvx kiosk demo), because I had a feeling it was well-behaved
with this stuff.
Same problem as latest code.
Error message this time:
failed hr, DXUT.cpp line 3484
Tested latest code again with
'favourNewDevice' forced false.Exactly the same behaviour.
Fed up with this now; it's 'fix creep'.Giving up and moving on.Span
mode doesn't even exist on Vista.
#revision
1527
EEK!Just noticed I'd left a temp test in
CMeshFrame::TestVisibility:
All the visibility testing of meshes, in perspective
mode, was being skipped in v19 - all meshes drawing all the time.Oops.(revision 1476)
Now fixed.
...and I'm amazed that this fix hasn't broken the shadows!They're still working!
Anyway, the skipped culling would explain the slowdown I noticed when I
tested v19 on the Z800 (it was only-just staying in 60).
Spot-checked occlusion culling
in multihead stereo mode.Working
(independently) in both eyes.
#revision
1528
Multihead second window now has
a "Please wait - creating new D3D device..." caption.The player sees this when alt-entering into
fullscreen multihead mode.This message
uses the current language at the point where the app is started; doesn't
change language on the fly.
TODO: proper in-game "please wait" messages.
Added an 'Apply selected mode'
option to the stereoscopy menu.
TODO: this is greyed-out until required.When it's enabled and it's pressed, it
recreates the device in the required format.In the case of applying a multihead mode, it will also switch the game
into fullscreen as required.<-done(16th)
14-août-2008
2,8
Yesterday's stereo screenshots
were taken using default settings apart from:
interpupillaryDistance:20.33174515
convergence:0.00000000
mode:ESTEREOSCOPYMODE_DUAL_MONITOR_2
TOFIX:
- drag game window to second monitor
- alt-enter into a multihead mode
- "Failed creating the Direct3D device"
#revision
1525
PHEW, managed to fix yesterday's
alt-tab problems in multihead modes:
Found that the multihead device is put into the LOST state when you alt-tab
away from it (makes sense i suppose, since we're stepping out of fullscreen
mode).
In revision 1287 I changed DXUT so that if we were trying to render, and
the device was lost, a new device would be created.That was a big help for span mode, but
turned out to be a bad idea when the device is multihead.
So I've now wrapped revision 1287's changes in an 'if(favourNewDevice)' - we still favour a new device in these situations except when the current device is
multihead.<-see revision 1540, 16th
When favourNewDevice is false (multihead), DXUTRender3DEnvironment doesn't get to
calling DXUTChangeDevice during a lost device; it just bails out of the
render.So bForceRecreateIfRequired (revision 1287) can be left true.
TOFIX: looks like there's
something slightly wrong with the mist movement direction in stereo modes;
this can be seen when convergence is zero and interpupillary distance is 20
odd.The rain angle is also suspect (maybe
just looks wrong because it doesn't match the mist movements).Need to test this thoroughly again.
Re-tried the test of switching
between horizontal and vertical span mode while the game is
full-screen.
I'm sure this used to work nicely since revision 1287.
Now the call to DXUTReset3DEnvironment in DXUTChangeDevice is failing with
DXUTERR_RESETTINGDEVICE ("An error occurred when
attempting to reset an IDirect3DDevice9 device.").
#1
...checked that the v19 master
build definitely does work in that situation, and that the current master
build definitely doesn't (behaves same as debug).
So it's something that's changed since v19.Must be in DXUT, surely, and shouldn't be hard to track down.
13-août-2008
5
TODO: Since some stereo setups
use a mirror to reflect the second monitor over the first one, the
dual-monitor mode should provide the option to horizontally flip either the
left or right image (or both).
#revision
1523
Added new stereo mode
entries:
ESTEREOSCOPYMODE_DUAL_MONITOR_1
ESTEREOSCOPYMODE_DUAL_MONITOR_2
ESTEREOSCOPYMODE_IZ3D (note: no flipped version)<-see 17th; now have a _SWAPPED version
A quick google showed that "dual monitor" was a far more common
term (with "stereoscopic") than 'multihead'.
#revision
1523
Cool, I've got the two
dual-monitor stereo modes working now.Exits cleanly.
I never imagined it would be this easy!
reverted->
MOVEME?: DXUTChangeDevice: removed check: if(
!IsWindowVisible( DXUTGetHWND() ) )
to force ShowWindow for both windows when alt-entering.
TOFIX: this has the side-effect of bringing the mouse pointer on screen and
losing input focus on first alt-enter, until the mouse is clicked.<-(12th)
now removed the UpdateWindow
calls->
Re #1: the mouse pointer appearing was caused by the
UpdateWindow calls done when the two windows are created (UpdateWindow forces
a WM_PAINT).This also caused
RenderScene to get called before the mode stack etc. was set up.
For now, to match the multihead reference code, I've left the UpdateWindow
calls in and added a NULL modestack check to RenderScene.<-(12th)
#1
#revision 1524
Added function
g_game.IsSecondMonitorUsable.
False when windowed.TODO:
improve.
The function is used to skip second eye's render in
multihead modes.<-see #2
#revision 1524
DXUTBuildValidDeviceSettings:
added this line:
pValidDeviceSettings->numMonitors= pDeviceSettingsIn->numMonitors;
#revision 1524
Got
DXUTDeviceSettings::numMonitors hooked-up.
DXUTChangeDevice now picks up the changing D3DCREATE_ADAPTERGROUP_DEVICE
flag in this test:
So it forces a new device to be created when
alt-entering in multihead modes.This
is necessary (unless maybe I wanted to store a separate fullscreen &
windowed device simultaneously and just switch between them???To get any benefit from that, I think they
would each need to keep all their resources loaded at the same time; would
probably be disastrous.)
#revision 1524
As a result of the above,
alt-entering now works in multihead modes.
#2
#revision 1524
Had to remove the optimisation
mentioned in #1 for now, because it was preventing projector transitions from
working (not surprising that it would break stuff).Need a better solution, like a 'desired
stereoscopic mode' as well as the actual current one (which, when windowed,
would be 'none' standing-in for any multihead modes).
Alt-tabbing BACK to game in
fullscreen multihead mode:
DXUTChangeDevice gets to DXUTReset3DEnvironment, which reports
D3DERR_DEVICELOST
......
see bForceRecreateIfRequired, now forced false as a test.Alt-tabbing back, without recreating the
device, is successful about one in 3 times now; haven't spotted much of a
pattern yet....
TODO: get this working.<-sorted(14th)
DXUTCreateDevice now has a
number-of-monitors parameter.
DXUTGetHWNDDeviceFullScreen has a monitor index parameter that defaults to
0.
#revision 1515
Game is now creating two
windows; the second one is a child of the first, as in the reference
code.That means it gets cleaned away
automatically.Can't see the second
window yet.
#1
#revision 1516
MOVEME?: DXUTChangeDevice:
removed check: if( !IsWindowVisible( DXUTGetHWND() ) )
to force ShowWindow for both windows when alt-entering.
TOFIX: this has the side-effect of bringing the mouse pointer on screen and
losing input focus on first alt-enter, until the mouse is clicked.
<-reverted (13th)
#revision 1518
Changed DXUTDeviceSettings::pp
(presentation parameters) to be an array with DXUT_MAX_MONITORS elements.
TODO:
"The number of elements in
D3DPRESENT_PARAMETERS should equal the number of adapters defined by the NumberOfAdaptersInGroup member of
the D3DCAPS9 structure. The DirectX runtime will assign each element to each
head in the numerical order specified by the AdapterOrdinalInGroup member of
D3DCAPS9."
#revision 1519
Updated
DXUTBuildValidDeviceSettings to 'match' the D3DCREATE_ADAPTERGROUP_DEVICE
(multihead) flag.
#revision 1519
Now successfully creating a D3D
device with D3DCREATE_ADAPTERGROUP_DEVICE.
NOTE: Inverse blending is not
compatible with D3DSWAPEFFECT_DISCARD (which I'm using because it's
apparently the most effecient swap effect, and the one used in the multihead
reference code) :
"Applications that use D3DSWAPEFFECT_FLIP or
D3DSWAPEFFECT_DISCARD should not expect full-screen destination alpha to
work. This means that the D3DRS_DESTBLEND render state will not work as
expected because full-screen swap chains with these swap effects do not have
an explicit pixel format from the driver's point of view. The driver infers
that they should take on the display format, which does not have an alpha
channel"
#revision 1520
Each element of the 'pp' array
now has the correct hDeviceWindow when creating the fullscreen device.
#2
#revision 1521
Re #1: the mouse pointer
appearing was caused by the UpdateWindow calls done when the two windows are
created (UpdateWindow forces a WM_PAINT).This also caused RenderScene to get called before the mode stack etc.
was set up.
For now, to match the multihead reference code,
I've left the UpdateWindow calls in and added a NULL modestack check to
RenderScene.
<- now removed the UpdateWindow calls (13th)
Kewl, the second window is
showing up on the second monitor now (flickering and empty).It's definitely the second window, as seen
from its title bar.
Alt-entering back to windowed
mode:
device Reset fails with INVALIDCALL.Probably because I'm trying to reset a multihead device into windowed
mode, which isn't valid.
"When trying to reset more than one display
adapter in a group, set pPresentationParameters to point to an array of
D3DPRESENT_PARAMETERS structures, one for each display in the adapter
group.
If a multihead device was created with D3DCREATE_ADAPTERGROUP_DEVICE, Reset
requires an array of D3DPRESENT_PARAMETERS structures wherein each structure
must specify a full-screen display. To switch
back to windowed mode, the application must destroy the device and re-create
a non-multihead device in windowed mode."
#revision
1522
WIN!!
Successfully tested rendering to the second monitor!
See TEMP TEST at top of C_HDR::BeginScene
An evening well spent :D
11-août-2008
1,83333
Back from a two-week holiday.
Remembered I don't have
catch-all forwarding for programmerart.org.So all the times I've been submitting ad-hoc @programmerart.org
addresses on sites (as a spam-limitation measure), they won't have been
working at all.
That'll learn 'em.
I'm now going to concentrate on
adding those last few missing stereoscopic modes (mainly dual-monitor and
iZ3D).
If that goes well, I'll apply for certification of native stereo support at
MTBS3D.com.
Added DXUT_MAX_MONITORS, the
maximum supported number of monitor outputs.
Changed
DXUTState::m_HWNDDeviceFullScreen
to
DXUTState::m_HWNDDeviceFullScreenArray[DXUT_MAX_MONITORS]
SetHWNDDeviceFullScreen and GetHWNDDeviceFullScreen now take a monitor
index paramter.
Changed
DXUTCreateWindow
to
DXUTCreateWindows, which takes a number-of-windows parameter between 1 and
DXUT_MAX_MONITORS inclusive.
Remmed-out DXUTSetWindow which
was unused and now OOD
DXUTGetHWND now takes an
optional monitor index (defaults to 0)
The award for Most Hassle Caused
by a Visual Effect goes to:
rain splashes, for The Trouble They Cause in
Stereoscopic Modes.
#revision 1509
TOFIX: There is an ordering
mixup that was causing the rain splashes to be out of sync between the eyes
unless I prepped CRainImpact before drawing the second eye.<-EXCEPT IN ANAGLYPH
For now, I've got them in sync by doing
that.
<-FIXED: the two-frames-per-frame
eye-toggling was being done before the render instead of after.Now moved up to RenderScene (from
CModeEnvironment::Render)
NOTE: made the corresponding re-fix in HDR.cpp (see clearLDRBackbufferOnce)
#revision 1510
Improved rain splash brightness
consistency, for varying sizes of ERENDERTARGET_RAINIMPACT_SPLASH_DEST, by
not affecting the height sample spacings according to the dimensions of that
render target, only its aspect ratio.
See RAINIMPACT_SPLASHNORMALS_HEIGHT_SAMPLE_DENSITY
#revision 1511
Related to the above, the other
half of the brightness inconsistency in the stereo modes was being caused by
the defaultOverrides files specifying shadows\sourceRT=/1 and
shadows\destRT=/2.
Investigation might be needed there.
For now I've removed those lines from all the defaultOverrides files.
#revision 1512
Lights can now be toggled back
on again.
#revision 1513
Frame-sequential stereo now
updates between the eyes.<-undone this; performance is
already as low is as it can go without losing Z800 stereoscopy.Need to optimise stuff shortly.
I'll release v19.0 tomorrow
23-juil-2008
2
#revision 1505
Default fullscreen res is now
1024x768.
TODO?: should default to using desktop res?What do other games do?
#revision 1505
TEMP: disabled everything on the
Display menu apart from the full-screen toggle.
People are constantly getting confused by those controls that don't work
yet.
I will get them working soon.
#revision 1506
Blaster sound now triggers
correctly on each shot (with overlapping samples).
#revision 1507
Added a NULL check round the
blaster sound play.TODO: missing
samples need to be handled better, by the sound manager probably.
The NULL check should prevent the crash I was getting on Vista 64 (I assume
that's all it was).TODO: debug the
missing-sound problem on Vista 64.
#revision 1508
AddedCLightManager::RegisterLightVisibleInMainDraw
This prevents a couple of bugs:
- when cycling through the stereoscopy modes, the number of visible light
would previously keep increasing and not have the chance to reset (now
prevents duplicate entries in the visible lights list).
- previously there was no check for the maximum number of visible lights
being reached (now bails out when this limit is reached).
#revision 1508
CBlasterEffect is no longer a
temp-friend of CLightManager.
CLightManager::numVisibleLights and numVisibleLightsInMainDraw are now
private.
Website: Tried to get an icon
working, by adding this to the 'head' block of Default.master:
Fixed the remaining problem
cases with the blaster lights and projector transitioning.
The projector transitioning now seems [perfectly?] stable even with three (or presumably more) projectors!
:)
<-update: they do still suffer from
fade-right-out-before-fading-back-in, but that's a really minor problem in
the grand scheme of things - I'll fix it another time if I need to.I'm bored with projector transitions now,
and they've had their fair share of my time.
All safely checked-in in revision 1502; now to tidy-up.
#revision 1503
Tidied a bit by adding CLight::flags.borrowingProjector
used by blaster lights when they're stealing a projector.
Projector assignment loop now also handles 'visible' lights that aren't
enabled this frame (see explanation in comments).
21-juil-2008
4,3
Spent pretty much the whole
evening trying to get the blaster shadow projectors to play nicely with the
projector transitioning.Surprisingly
difficult.Working now, except TOFIX: the blaster shots
don't seem to obtain a projector when there are no other lights around.Shouldn't be hard to
fix that.<-FIXED (22nd)
TODO: lots of tidying needed (or "I think
we could do with a mega-tidy-out in here, don't you?")
20-juil-2008
7,5
This seems to be the right
syntax for linking to a YouTube video in its own page (nice big frame, no
junk) :
Ditched Friday (18th)'s version
of the projector assignment loop.I
had gone off the tracks a bit and it had become more complicated than it
should have been.
The previous version seems to be slightly less glitchy than it was,
presumably because of changes made peripherally on Friday.For a moment I even thought it was fully
working, but no.
The projector assignment loop
only appears faulty when the number of projectors is 3 or more (I
think).
Since the default is 2, I'm going to move on because there are more
important things to do.
Lighting geometry (the geometry that renders the deferred lighting) wants
improvement, but it's low priority.In
lighting-only debug mode, the problems are much clearer than in normal
mode.<-Actually it is quite noticeable in the game :(
Should really be using meshes instead of spritey-things.
Renamed CCullPlane::exclusionBit
-> indexBit
Added
CCullPlaneUser::cullPlanePenetrations
Couldn't find any pre-written
way in MAXScript of testing for intersection between a light and a plane.
CullPlaneUser now inherits from
CListItem
Found some glaring problems with
the CullPlaneUser 'penetration handling' added on the 14th of June.
Fixed it right up.Also reduced
LIGHT_AABB_BOUNDINGRADIUS_MULTIPLIER, which makes a big difference to how many
lighting pixels are drawn each frame.TODO: lights should fade in and out as they cull.
Increased the range of the John
Street big white light.Makes the
place look totally different (and more like the real location).But I need angle limits on the lights, for
performance and for realism - TODO
It's also clear that I need to reflect those shadows.Looks very wrong that the shadows aren't
reflected.
TOFIX: crash when firing!<-fixed (was assigning a projector to blaster lights before
the light's bounds & centre were set up)
18-juil-2008
3,333
Completely re-wrote the
projector assignment loop, but it's still wrong.It's horribly complicated and I hate
it.The most frustrating thing is that
I can't even work as late tonight as I normally would do to get it
fixed.I just have to stop now, having
made no progress, and leave it till Sunday.
17-juil-2008
3,5
Another possible stereo mode:
SIS™
http://www.sis3d.co.uk/9344/index.html
Seems to be simply over-under (right eye on top), tipped anti-clickwise
90°
Ultra low priority, because video drivers let you rotate the display anyway.
#revision 1489
Projector transitions are now
95% working.There's one little glitch
case that can be seen in the west alley of Bedford Court.Shouldn't be hard to track down.
TODO: simplify/tidy the projector assingment loop.
TOFIX: rain splashes seem to be
double-bright in stereo modes.
Also, they match up really badly between the eyes.Am I updating them in each render or
something?
Rain splashes are now the only effect that's letting down the stereo.Anything that lets down the stereo is
pretty embarrassing.Shadows are now
perfectly stereo-friendly.
Maybe to improve stereo consistency of rain splashes:
- don't influence them by the normals behind them
- use world-space position (rather than screen-space) to lookup the detail
texture.This should also prevent some
shimmering when the viewpoint is travelling.
TOFIX: Post curve: doesn't match
with Photoshop results!
Moved projector assignment into LightManager::Update
TODO: get blaster shadows working again
#revision 1484
Projector (shadow) fade-ins are
now starting to work.They look really
nice.Kinda dream-like in fact.
The fading uses CHomer, the same class that produces the smooth menu
transitions.
Changed the shadowmaps to use squared distance.This saves zillions of pixel shader sqrts
per frame.
Had to upgrade PROJECTOR_ORT_FORMAT to D3DFMT_R32F for this; the float16's
were having none of it.
I wasn't using the green channel anyway; light filter textures will be
applied from the receiving end.
NOTE: the z buffering used during projector depth draws is now squared 0..1
depth as well.Doesn't seem to cause
any trouble.
Also reordered the ProjectorShadow PS for efficiency.
#revision 1478
DeferredLighting.fx: For lights
with projectors, specular is now blocked by fallback shadows as well as
projected shadows.This will be tidied
when I add the projector cross-fading.
14-juil-2008
2,66667
#revision 1474
Added
CLight::priorityMultiplier.This is
used by blaster lights to pretty-much ensure that they always cast
shadows.
See LIGHT_GETPROJECTORPRIORITY_BLASTER_INFLUENCE_FACTOR (todo: tidy)
#revision 1475
Added CViewInfo::Update
(once-per-frame update of g_viewInfo).Each frame, this tests one of several rays against the
environment.The minimum of the most
recent ray test results (currently 4 frames' worth) is stored as
g_viewInfo.shadowFrustumMinZ.This is
used, in combination with data about each light's view-space bounds, to
control the near & far distances of the frustum used to generate shadows.
Realised I'd overlooked
something with this adaptive frustum stuff:
Using the view-space light bounds to limit the frustum dimensions is fine
for diffuse light, but useless for specular light since it has no distance
falloff in my lighting model.D'oh!
I think what I need to do is use fallback shadows together with the projected
shadows, to block the specular.
I'll get that working<-DONE(15th)
when I do the projector cross-fading (starting tomorrow night).
TODO: change projector depth
images to use squared distance.Probably need to keep that second channel for mask/overlay textures.<-DONE(15th)
13-juil-2008
9,25
#revision 1468
Made a partial fix for the
projector culling problems.This fixes
the cutting-out shadows of the pillars in the BT building.
I had been forgetting to:
- actually use the FOV
angles calculated in CProjector::GenerateDepthImages
- set the aspect ratio for the projector camera (this now happens
automatically in CCamera::CalculateProjection; added an aspectRatioDirty flag
to the cameras).
CCamera::CalculateProjection is now being used again; before it had been
duplicated into CViewInfo::ApplyCamera during headtracking improvements.The (virtual window) headtracking now
updates the FOV of the camera itself; so everything should still work
properly.
#revision 1469
Eventually cornered my projector
culling bug.Funnily enough it was
exactly what I'd guessed it was: shear in the view matrix.I don't yet know what it is about TestSphereVisibility that doesn't
support shear, and I'm not sure I've got the time to investigate.For now what I've done is just remove the
shear from the view matrix for the projector depth draws (CProjector::GenerateDepthImages).There should be no practical difference
anyway; the important thing by far is just to make sure that sphere culling
is being used for these depth draws, and it is.Let's move on.
#revision 1470
Further hacky fix to reinforce
revision 1465.Reactive scenics with
'dynamic bounds' set true now ensure that their parents' bounds are at least
as big as their own.
This assumes the parent's centre matches this centre (like I say, hacky,
but it does its job).
#revision 1471
Little fix to the new aspect
ratio stuff - there was an ordering/dependency bug.
So, now I'm FINALLY at the stage
I'd hoped to be at by yesterday afternoon - ready to start on the
adaptive-frustum stuff that will maximise the res for the shadows.
Added a draft version of the
adaptive-frustum stuff.It's already
working wonderfully.
Also improved the blaster's
assisted aiming so it works with the ground plane as well as the landscape
meshes (it doesn't actually test the ground mesh yet, but the ground plane
seems to work well enough from what I've seen).
12-juil-2008
6,3
#revision
1462
The soft
shadows option (the option to turn softening off)
now works, and works as an optimisation.
Tried using a half-pixel UV
offset on the shadow depth lookup.Didn't seem to be the right thing to do:
C:\Noctambule\Debug\12_7_8_FFSM_shadowDepthHPOffsets.psd
#revision
1463
Shadow depth, when written to
the depth maps, is no longer divided by PROJECTOR_DEPTH_RANGE.
Projectors now clear their depth maps to zero, and ProjectorShadow.fx bails
out if it reads zero from the depth map.
#revision
1463, 1464
Changed the shadowmapping to
work on true distance from the light rather than distance along the light's
direction (to the frustum face).
In some extreme cases where a frustum face was close to the light, the old
method clearly wasn't up to the job, because part of the frustum face would
(correctly) be a negative distance along the light direction.
That had been the cause of the mini-gaps that I mentioned last night - I'm
glad to see them go :)
Following-on from the above, a
possible optimisation later would be to use the new distance calculation only
in those extreme cases (a spare colour channel would indicate which of the
two methods to use for each pixel of the depth map).
Briefly had a bug where I'd
forgotten the 'out' direction specifier on a vertex shader parameter.
I would have hoped the compiler would tell me about something like
that.It had no semantic - it should
have been obvious that I wasn't trying to use it as an input.
#revision 1465
D3DXFrameCalculateBoundingSphere
doesn't seem to take into account scaling animation.
Because the lampposts use bone scaling to correct their size, the
lampposts' bounding radii were too small.
I've now added a slightly hacky fix in CReactiveScenic::UpdateVirtual.A 'dynamic bounds' flag is set true by
lampposts so that each frame the bounds update to contain all the bone
positions.
#revision 1466
Added option debug\lockProjectors.This freezes the
assignment of projectors to lights.Handy for debugging a particular lightsource.
#revision 1467
DeferredLighting.fx: added
classic halo removal for the soft shadows.
TOFIX: I'm having some problems
with TestSphereVisibility in the projector depth draws.This is probably something to do with the
unusual sheared view matrices that they use.It's causing bits of the shadows to cut out sometimes.<-FIXED(13th) TestSphereVisibility doesn't support a
sheared view matrix.
11-juil-2008
3,666
#revision
1460
Cleared up all the errant
back-projecting shadows (ProjectorShadow.fx)
I think the very last artefacts
I'm now seeing, in the case of a point light very close to a casting object
(lampposts), is down to a natural discontinuity in the projected shapes of
the casting object on the different frustum face maps.
I think.It's certainly a convenient
explanation, because it means the problem is un-fixable.It's fairly minor anyway.So it means the whole effect is working
properly.
C:\Noctambule\Debug\11_7_8_final_FFSM_artefacts.psd
...actually, there's seems to be
one little bug left that shows up occasionally.I'll weed that out tomorrow<-FIXED(12th) and then start adding the adaptive
frustum stuff that minimises the length of the frustum to maximise the shadow
res.
9-juil-2008
0
Note to self: don't get involved
with editing Wikipedia pages - it draws you in!!
I sort of lost the whole evening doing this :(
8-juil-2008
2
Got the far face of the view
frustum shadowing properly.
TOFIX: the first bailout in the
ProjectorShadow.fx pixel shader needs to use the normal of the frustum face,
not the light's view direction.
Bought the cheapest domain name
ever: shadowmap.info for 99p
!?From 123-reg.co.uk
#revision
1443
Added
SEnvironmentRenderData::pOriginalCamera.Fixed a place in CModeEnvironment::RenderSubset where the
player/flycam camera was getting applied even if the render category was
projectordepth.Not sure what effect
that was having if any.
CProjector::GenerateDepthImages now restores (re-applies)
SEnvironmentRenderData::pOriginalCamera after generating the depth
images.
CModeEnvironment::Render no longer applies a camera (because RenderEye does
this before drawing).
CModeEnvironment::RenderSubset:
prevented unnecessary Z buffer clears for redraw effects.
GRR, I've been debugging the
wrong frustum face for the past....grrrrr
DX:
D3DXMatrixPerspectiveOffCenter is misleading with its parameters; see
explanation here:
http://discussms.hosting.lsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0011A&L=directxdev&D=0&T=0&P=6897
Checked that SViewFrustumPlane
normals and plane equations are still needed.
Eventually got the new shadow
res bias working on the four long faces of the view frustum.I'm relieved that the faces all more-or-less join up now (edges and
corners pretty-much
line up).However
there are still little gaps...they look like they shouldn't be too hard to
track-down or bodge away.Hopefully
I've just made a silly mistake somewhere....<-FIXED(7th)
Anyway, the work has paid
off.The serious gap problems I had
before are fixed; the overall apparent res is much higher; these shadows are
doing some REALLY good stuff now.When
you get up close to them they are pin sharp :)
I seriously expect it would be
possible to patent this shadow technique, but I'm not sure I'd want to.I think that would make it less likely to
get seen, used and appreciated.
Instead, I'll probably just give it a fancy name, write a little document
about it and see if it becomes popular.Depending on how that goes, I might do the same for some of the other
effects.All good stuff for the
website.
Realised something important
about my shadows:
The projector view that I've been setting up to point at the frustum face
has got no relationship with the view that I actually want to use to render
the casting geometry flattened onto the frustum face.It's good that I'm setting up the view,
because it's appropriately used for culling.But when I draw the projector depth I should actually be looking along the frustum face from the
narrow end (the face-space offset of the viewpoint from the face's
left->right line should have a zero Y component).
In other words, once I've
flattened the casting geometry onto the frustum face, I'm free to use
whatever viewpoint I want to render that geometry to the depth map.The ideal viewpoint is one that fits the
face perfectly into the viewport.
Hah!There is another missing half-pixel offset
in ProjectorShadow.fx, in amongst all the crazy projection trickery.
TODO: fix<-was already fixed I think
I think my shadows could
generate depth images for several (three?) frustum faces per draw, using a
geometry shader.But that won't happen
for this project because this project is not going to move onto DX10.
Spent most of the evening
working out how to set up the view so that each frustum face will exactly
fill the viewport.
Max was very helpful for this:
C:\Noctambule\Mockups\newResBias.max
Started adding the new shadow
res bias code.Will get this working
tomorrow.
4-juil-2008
2,75
v18 bugs on Quadro / Vista
64:
C:\noctambule\debug\v18_0_quadroBugs_vista64.psd
ESHADEREFFECT_RAINNORMALS is
written-to in CRainImpact::Render, which is called earlier than when the
lighting is generated.
ESHADEREFFECT_SHADOWBLUR is written-to in CLightManager::GenerateLighting \
CProjector::GenerateShadows.
It almost looks as if SHADOWBLUR is writing its output into the splash
(alpha) channel of its render target.
It's not though!It's writing zero
alpha.And it draws after the rain splashes
are done anyway.And the rain splash
effects all draw without blending, and *now* without alpha testing.Maybe it was just failing an alpha test???We'll soon find that out.
RainNormals.fx: changed it from
using bizarre (but mostly ok-looking) renderstates to using ALPHATEST=FALSE,
ALPHABLENDENABLE=FALSE
RainSplash.fx: fixed some
sampler filtering.
Sent myelf some new FXOs to try
on the Quadro, with the fixes described above.
#revision
1434
RainSplash.fx: Added missing
half-pixel offset.
Anyway, this weekend is SHADOW WEEKEND!That means I finally get round to attacking
all those glitches that have been ruining the shadows.
This has been on my to-do list since May 2006 when I concocted this shadow
technique of mine (which still doesn't have a proper name).
Tracked-down & fixed the
problem that was vertically flipping the blaster streaks in
screen-space:
When I changed several shader effects to use input.uv instead of converting clip-space position into UV, I
accidentally left the line in that negates the Y component.So I had vertex shaders doing this:
output.uv= input.uv; output.uv.y= 1.f-output.uv.y; // this is just left-over from when clip-space position was
being converted to UV
The vertex shader that was flipping the blaster streaks was in
MotionBlur.fx (CombinePass).
#revision
1431
MotionBlur.fx: Made a correction
to compensate for the fact that the velocity buffer is an 8-bits-per-channel
int format.
When reading the velocity from the buffer, just had to subtract (127.f /
255.f) rather than 0.5f.
When the camera is still, the frame is now completely un-blurred :)
TODO?: To speed up the lighting,
get rid of the position buffer and instead use the W of the normals buffer to
store view-space Z position?
The question is: would it be faster to extract view-space/world-space
position this way than to read it from a 4-channel 64bpp screen-sized
RT?My gut feeling is that it would be
tons faster (in which case, why do people use position buffers??)
TODO: do a rough test to gauge the performance gain.
BlasterEffect: Fixed the stray
poly that was appearing on one of the streaks.Just needed to subtract 2 from the number
of prims to draw (ie. always remove the trailing degenerate quad because in
the case of the last projectile, it connects to nothing).
#revision
1432
Following-on from revision 1431,
made a corresponding fix in Velocity.fx.Needed to do this because it seemed that the X1900 was definitely
rounding 0.5f up to 128.f/255.f, causing different
results between the two machines.Slightly worrying, that.
The fix was to offset the output of Velocity.fx by
(0.5f-(127.f/255.f))
This fix is future-proof in that it would allow the velocity buffer to be
changed to floating-point (if I had any reason to), without me having to
adjust the shader code again.
TOFIX: I seem to have broken
BlasterEffect in a bizarre way.When
motion blur's enabled, the Y axis of the projection matrix is negated (????)<-FIXED(3rd)
30-juin-2008
3,5
Found that the
'halfScreenPixelOffsetsIn' parameter of UtilDrawScreenQuad was defaulting
false!
Now fixed.
Found that the half-pixel
offsets applied by UtilDrawScreenQuad were always screen-res half pixel offsets, not current RT.Now fixed.
#revision
1426
DeferredLighting.fx: Tried loads
of different ways of combining the clean and blurred shadow images.What seemed to look best in the end was
pretty much what I started with (nice & simple), but with a wider blur
and a shorter clean-to-blurred blend range.
Shadows are looking a bit nicer now.
ShadowBlur.fx: Added missing
half-pixel offset and corrected the alignment of the blur.
Yesterday's strange stepping
pattern now seems to be fixed in windowed mode, but not fullscreen.
29-juin-2008
8,16667
Dreamt about half-pixel offsets
all night.Once I've finished this
project, I really need to get out more.
#revision
1413
(below) Stumbled on something
that could be useful - a shader effect that seems to calculate the distance
of each pixel from the centre of its face - or something like that.Don't ask me how it works!
Almost looks like something that could be used to counteract SSAO
'facetting' artefacts ?
The pattern is just as strong at any angle, but weakens with
distance.
C:\Noctambule\Debug\29_6_8_showDistFromFaceCentre.png
FallbackShadowReflectionPosition.fx
#revision
1414
FallbackShadowReflectionPosition.fx:
Tried to rearrange this so as to remove the sqrt from the pixel shader.
Found that this wasn't possible because of the way I'm using a threshold
value in the comparison between the receiver depth and the scene depth.
(A-B==threshold) != ((A*A)-(B*B)==(threshold*threshold))
I've done some repair work on FallbackShadowReflectionPosition.fx
to make it cleaner & more accurate.
#revision
1417
FallbackShadowReflectionPosition.fx:
Noticed that the deferred lighting samplers (position, normals) were using
linear filtering (???)Now using
point.
No visible difference on the X1900 (it can't filter floating-point
textures)
#revision
1418
ERENDERTARGET_RAINIMPACT_SPLASH_NORMALS
now shares with ERENDERTARGET_PATCHWORK_DIMPLENORMALS.
Previously it shared with ERENDERTARGET_REFLECTION_DIFFUSE.
So the splash normals are now generated on a fixed-point render target.This gives a per-light saving (when
sampling the splash normals), and per-light savings are the best kind.
#revision
1418
ERENDERTARGET_PATCHWORK_DIMPLENORMALS
now defaults to half-by-half size rather than quarter-by-quarter.
Previously, the dimple normals were a big source of blockiness that
couldn't really be ignored.
The generation of the dimple normals (PatchworkDimpleProcessing.fx) is not
the cheapest of pixel shaders, but I've seen worse ;)
#revision
1418
#revision 1419
DeferredLighting.fx,
RainNormals.fx: Tweaked the way the rain splash normals are used, to get them
looking right again.
Removed a normalise.<-D'oh!
No, forgot that auto-reloads aren't working in full-screen
#1
#revision 1420
ERENDERTARGET_FALLBACKSHADOWREFLECTIONPOSITION
now shares with ERENDERTARGET_MOTIONBLUR.
Previously it wasn't sharing.
NB. It is now full-res.This removes
specular fringes that were previously seen round objects due to fallback
shadows (previously it was a half-by-half RT).
#revision 1424
Tried making
ERENDERTARGET_RAINOCCLUSION share with ERENDERTARGET_REFLECTION_DIFFUSE, but
the ordering got tangled.
Previously it shared with ERENDERTARGET_FALLBACKSHADOWREFLECTIONPOSITION
but now that's gone full-res (see #1).
Decided to make ERENDERTARGET_RAINOCCLUSION a non-shared RT instead.
Added option weather\rainOcclusionRT.Currently defaults to
512x512.
CAnimMesh::Render no longer sets
an identity object matrix before and after drawing, and it now ignores the
current object matrix.
#revision
1421
v18 bodge:
CAnimMesh::Render bails out if render category is
ERENDERCATEGORY_RAINOCCLUSIONDEPTH.
This is because anim meshes have been making a nuisance of themselves in
the rain occlusion draw.
TODO: probably need to fix this at some point!
#revision
1422
v18 bodge: toggling
fullscreen no longer flags an override of the 'display\fullScreen'
option.So the game will always start
windowed unless the config file is edited manually.
This prevents a startup crash seen on Vista 64 when launching the game in
full-screen.
TODO: INVESTIGATE!!!
#revision
1423
CLightManager::DrawPlaceholderLightObjects
no longer includes blaster lights.
#revision
1424
Added the required half-pixel
offsets to the following shader effects that use non-screen-filling geometry
to sample screen buffers (positions, normals, etc) :
DeferredLighting.fx
FallbackShadowReflectionPosition.fx
TODO: resolve duplicated code for this.
Didn't manage to release version
18.0.
1. On the slave, when the frame RT is reduced
(anaglyph, WOWvx), there's an odd stepping pattern round the edges of things
(noticeable on cars).This doesn't
happen at all on the master PC.<-FIXED(1st
Aug)
2. There's a visible should-be-degenerate
linking quad hanging-off one of the blaster projectiles.<-FIXED(3rd Aug)
3. I want to try putting a little adjustment on
the motion blur, because currently the velocities are slightly offset.For example there's a slight blur even when
the view is static.This is because of
the lack of precision in the integer format used for the [blurred] velocity
image.<-FIXED(3rd Aug)
TODO: get those reflected
shadows working.
28-juin-2008
10,1667
#revision
1397
Blaster shots now terminate at
their impact point when hitting a zombie.This prevents noticeably upwards-pointing shots (due to assisted
aiming) when firing very close to the zombie (like, a couple of metres away).
In the most extreme case of the assisted aiming, the viewpoint is inside
the zombie's collision sphere when the shot is fired, so the shot heads
directly up to the viewpoint.
#revision
1439
Added Vec3IsIdentity: determine
whether or not the specified 3-element vector is zero-length
#revision
1400
Found that the BlasterEffect
render can run into a freak problem case where the streak has zero length
(this is valid).
This case is now detected and handled by simply hiding the projectile's
verts rather than plotting them into position.No point adding complicated code to handle
a one-in-a-thousand case - just let the projectile become invisible.
#revision
1401
Added CModeEnvironment::TestRayIntersection.This performs:
ray collision on the zombies (currently ray-sphere with culling:
CZombieManager::TestRayIntersection);
ray-mesh collision on the landscape, using D3DXIntersect
(CLandscape::TestRayIntersection).
The closest T value is passed out in a CEnvironmentCollision instance.
#revision
1402
Ray-landscape collision now has
hierarchical bounds culling (ray-to-bounds).
TODO?: also use hierarchical bounds occlusion culling (CullPlanes)?The benefits of this would be fairly small at present, but would
increase as the complexity of the town increases.
Robot pirates?
#revision
1403
TEMP: Blaster shots now launch
from the player model's right hand
#revision
1404
Each blaster projectile can now
store information about a known terminal collision.This collision is found by ray-testing the
static landscape just before the projectile is launched.
If the projectile travels for as many seconds as it takes to reach the
known terminal collision, it terminates at that point.This prevents the need for the projectiles
to perform collision tests with the static landscape each frame.
#revision
1405
CBlasterEffect::CollideWithSphere
now correctly handles the case where the projectile's position and
previous-position members are equal.
#revision
1406
DeferredLighting.fx now skips
the sampling of a blurred shadow image (n/a) if the shadows are fallback
shadows.
This is done using a uniform parameter.
#revision
1407
DeferredLighting.fx: removed the
'diffuseShadow' uniform because it was only being used to indicate whether
the shadows were real or fallback.
TODO: cancel perspective for
texture sampling in DeferredLighting.fx and for other shaders that use the
same lighting geometry.<-Not needed, because the
geometry is screen-aligned rather than camera-facing
#revision
1409
Moved the generation of fallback
shadows into DeferredLighting.fx.The
benefits of this are:
- the fallback shadows now have higher resolution (reduces haloes round
objects)
- the fallback shadows are now only generated for the pixels that need them
(the pixels of the lighting geometry)
- saves various CPU & (mostly) GPU work
- gets rid of a little corruption/junk glitch I was sometimes seeing in the
fallback shadows at the bottom-left of the screen
#revision
1411
Removed everything to do with
the old separate-stage fallback shadows: FallbackShadow.fx,
ERENDERTARGET_FALLBACKSHADOW, etc.
#revision
1412
DeferredLighting.fx: Noticed
that the deferred lighting samplers (position, normals) were using linear
filtering (???)Now using point.
TOFIX: Realised that all my
effects that convert screen-space positions into 'screen UVs' are lacking
half-pixel offsets.Maybe that
explains the remaining slight specular haloes round objects?
27-juin-2008
3
DebugSphere now takes a vector
pointer instead of a reference.TODO:
same for other debug draw functions.
Noticed that D3DX has some
useful collision functions:
D3DXIntersect, D3DXIntersectSubset (ray-mesh collision)
D3DXIntersectTri
D3DXSphereBoundProbe (ray-sphere collision)
D3DXBoxBoundProbe (ray-AABB collision)
Added CBoundingBox::DrawDebug
#revision
1391
Determined that my AABB-AABB
collision is now working properly.
The collision failure in
CBlasterEffect::CollideWithSphere must be happening somewhere else...<-FIXED
#revision
1392
Fixed a problem with ray-sphere
collision.It was the way I was using
the t1 & t2 vectors....
The IntersectRaySphere functions now pass out a single T value.
#revision
1393
Fixed a clumsy mistake in
CBlasterEffect::CollideWithSphere (had been returning if T was out of range, instead of continuing to next
projectile)
#revision
1394
The IntersectRaySphere functions
now treat the sphere as 'solid' (filled).If the ray starts inside the sphere, the intersection point is the
start point.
#revision
1396
Blaster-to-zombie-sphere
collision is now fully working and properly culled.
TODO: blaster-to-landscape-mesh
collision.Use
D3DXIntersect to save time.
Should probably compare performance of D3DXIntersect for ground collision
against my current specialised ground collision, just as a test (there's no
way it should be as fast as my collision, but it will be useful to see how
much difference there is).<-DONE (28th)
26-juin-2008
3,16667
#revision
1384
Grr, DebugSphere doesn't work at
the moment.<-FIXED (just needed to 'apply' the current
main camera)
#revision
1385
Added CZombieManager::DrawDebug
#revision
1386
#revision 1387
IntersectRaySphere now takes a start point and a direction vector.
Added IntersectRaySphere_StartEnd which takes a start and end point.
#revision
1388
Added Vec3ScaleAdd - better late than never.
#revision
1389
Added a discreet assisted-aiming
feature that makes the crosshair more meaningful.
When you fire a weapon, the enemies are checked for intersection with a ray
that casts from the viewpoint out through the crosshair (TODO: landcsape
collision too).If an intersection
point is found, the shot is launched directly towards that intersection
point.This aiming assistance is not
'noticeable' to the player but it gives them exactly what they expect - an
impact point right on the crosshair.
TODO: fix the bounding box
intersection test in CBlasterEffect::CollideWithSphere which is often returning an incorrect false result.<-FIXED(27th)
Started avoiding backward loops
because apparently they tend to make very poor use of the data cache.
#revision
1378
Fixed my bug where the blaster
lights were re-appearing after their shots had finished.This was something really stupid - I had
forgotten to hook-up the 'shootable' flag on the lights.Old lights were therefore getting toggled
back on by new shots.
#revision
1378
Blaster shots now have a limited
lifespan.
Lights default non-shootable, to
save confusion.Lights parsed from the
world file are all flagged shootable when they are parsed.
#revision
1381
Collision.cpp: Got rid of
IntersectRaySphere2, which was a temporary test.
#revision
1380
Added CBoundingBox
(BoundingBox.cpp&h) : An axis-aligned bounding box
Blaster effect now has an
overall bounding box that contains all projectiles.
#revision
1382
Blaster projectiles now collide
accurately with the zombies' heads.
TODO: need to fix the skydome so
that it doesn't get in the way of weapon projectiles (need to make it
infinitely distant)
15-juin-2008
10,1667
Improved the 3DVisor default
stereoscopy settings, by adjusting 'display width' & 'viewing distance'
Motion blur: Ideally, I wouldn't
smear the HDR backbuffer; I'd smear the scene diffuse and the scene
normals.Separate motion blur would be
applied to the lit reflection image(s), based on the velocities of the reflected views.
This would mean that flat reflective surfaces moving through the frustum
wouldn't incorrectly smear the reflection.
There's a slim chance I could make this change later.CViewInfo now stores the previous
world->view matrix for each eye, for each
render category.The reflected previous world->view matrices are used by CBlasterEffect
when drawing in reflections.<-had to remove
this because it meant the reflections were double-smeared
#revision
1373
BlasterEffect: Motion blur: In
EYE style, the persistence value is used and the streak is consistent in
strength across frame boundaries (as much as possible; the overlap messes
this up slightly).
In FILM style, the shutter angle value is used but with a floor of 180º
(lower than that, the streaks look naff).
NONE behaves like film-style with a shutter angle of 360º.
Blaster shots are now drawing
nicely.
#revision
1377
Blaster shots now collide with
the ground plane.
I expect I'm going to add full per-poly landscape collision soon.Maybe collision tests on the ground mesh
should be culled-off if they don't hit the ground plane.
Blaster shots now each have a
point light.
14-juin-2008
10,3333
From yesterday:
"I'll remember for next time - the better way to do split-screen
stereo is using viewports."
Thinking about this again, I remember why using
viewports isn't ideal either.It's
because HDR bloom & glares would leak over the edge of each viewport into
the other one (the HDR effects would treat the split screen as a single
image).
Losing eye-style motion blur (downgrading to film-style) is definitely
better than having HDR effects leaking between the eyes.
TOFIX: lighting-geometry seems
to be really wonky when generating the reflection image.<-fixed
#revision
1357
I'm now using a release version
of EMADevice_DLL.dll
The master build of the game project no longer fails
its post-build step (the release dll is now where it should be; the
post-build step copies it into the Master folder)
#revision
1357
Fixed quite a few 'assert' bugs
(function calls being used as 'assert' conditions, and therefore being
skipped in master builds).These were
the bugs I saw in v17.5 last night - all fixed now.
#revision
1358
LightManager::GenerateLighting:
the prep-type stuff (checking light priorities and assigning projectors
accordingly) is now only done for the first eye.<-TODO?Had to put this back because it could cause
a crash (select a stereo mode, look straight down, run around)
#revision
1359
CModeEnvironment::RenderSubset:
Made a fix so that during a reflected draw, the view matrix isn't
un-reflected (by CCamera::Apply) before generating the lighting.
After making this change, I had to fix the RespondToTestShot functions so
that they get a view direction from the player's camera rather than from
g_viewInfo.
Vec3DotXZVec2: what a winner!
#revision
1360
#revision 1364
#revision 1365
CCullPlaneManager::TestOcclusionVisibility:
Added a little improvement that allows an object with its centre on the far
side of a cull plane, and its occlusion corners both overlapping the plane in
screen space, to be deemed occluded even if its bounds are poking through the
cull plane (towards the viewpoint).This was needed because I was seeing some lights failing to get culled
by the double-sided cull planes around the BT building (because the lights
are close to the cull planes).
The new behaviour is controlled by the 'handlePenetrationIn' parameter
(defaults false; only used by CLight).
NOTE: When I tried having this behaviour active all the time, it caused
some objects to cut out when they shouldn't.So it might need a bit of improvement later.<-might be better
now
Seems to work fine with all the lights though.<-I did see one
cutting-out occasionally....
Reflected lighting geometry no
longer has tails.
Also fixed faulty 'sliding' UVs on lighting geometry:
Removed CLight::s_handleTilt (now always true).
CLight::ClipLightingVertsToViewportEdges: removed UV in/out parameters
(they were only needed in the old non-tilty version of the lighting
geometry.They were still being used
though, which was the cause of the bug)
#version
17.5
Released v17.5
#version
17.6
Released v17.6
This fixes a menu crash on startup when launching the
game with a headtracker attached.
TOFIX: 3DVisor 'keep alive'
messsages aren't working [on the master PC, master builds].
13-juin-2008
3,66667
Realised that the way I've done
my split-screen stereo modes doesn't allow for eye-style motion blur.This is because the two eyes render to the
same HDR backbuffer area (before being positioned on the required part of the
screen).It's the HDR backbuffer that
persists in eye-style motion blur (the motion blur is quite rightly
HDR).
I'll remember for next time - the better way to do
split-screen stereo is using viewports.
It's possible that I could find time later to make the change so that
eye-style motion blur will work in these modes.It should be an easy job, but it's also
very low priority.It would allow rain
to render directly to the screen in most of the split modes.
<-see 14th
COption::ApplyAll now forces all
variable menu items in the pause menu tree to update their variable
verts.
It's brute force again, because time is short.
Added CMICombo::SetValidValues and CMICombo::IsValueValid
These are used to disable the eye-style motion
blur option in stereoscopy modes that aren't compatible with it.
Built a version 17.5 in the hope
of releasing it tonight, but it has a few interesting bugs....
12-juin-2008
1,83333
Frozen pause backgrounds were
not working for split-screen stereo modes so I've changed them back to
non-frozen.
In theory they should be able to work, but I don't have time to
experiment.
Maybe the problem is that the first frame, after changing the stereo mode, has a faulty view setup
- and that's the frame that gets frozen and displayed until the mode is
changed again.
#revision
1351
Fixed a little ordering problem
in COptions::ApplyBeforeDeviceCreation:
Needed to call ApplyAspectRatio before ApplyFOV.
The problem showed up as an incorrect FOV when switching from WOWvx to the
next stereo mode, using override profiles.
#revision
1352
CMenuItem: Added flag 'resetDeviceOnChangeOfValue'.Currently used by CMIRenderTarget and by
the stereoscopy mode combo.
This causes all game modes to be invalidated and then restored, after the
options have been applied, whenever the item's value is changed.
Changes to render target dimensions (when switching between override
profiles) are now fully working.
#revision
1353
CLightManager::ApplyLighting:
Anaglyph mode no longer forces motion blur off.
Checked that new eye-style motion blur works in anaglyph mode:
debug\12_6_8_anaglyph_eyeMotionBlur.png
11-juin-2008
4,16667
Realised that eye-style motion
blur (in which each frame persists over subsequent frames) isn't compatible
with 'two-frames-per-frame' stereoscopy modes (line-sequential,
checkerboard).It's not compatible
with frame-sequential either.
In those modes, eye-style motion blur will be (todo...) forced to draw as
film-style motion blur.
#revision
1350
I'm adding a new
option overrides system that, for example,
automatically configures the optimal render target sizes for each stereoscopy
mode.
Each option enumeration value can have an override profile associated with
it; they're kept in profiles\defaultOverrides and they're named according to the value name.
So for example defaultOverride_ESTEREOSCOPYMODE_WOWVX sets the res to 1920*1080, the frameRT to half size, the
aspect ratio to 16:9, etc.It would be
automatically loaded at the start of the game if launching in WOWvx mode; and
automatically loaded when selecting WOWvx mode from the stereoscopy menu.
I'm not sure why freezing the
pause background in interlaced/checkerboard stereo modes didn't work.
In theory it should be possible; seems I've just not got some ordering or
something set-up how it needs to be...
For now I've kept it non-frozen in those modes.
I've still got various problem
cases to work through with the option overrides system, but it's basically
working and I'm pleased with it.
It also seems that updating render target options on the fly isn't as
complicated as I might have thought.The simple brute-force version is just an invalidate-reset-restore of
the device, same as what's done in Reload and on alt-enter.
So I'll get that working at some point in the next couple of days.It's good to see the menu functionality
edging towards completion.
10-juin-2008
4,5
#revision
1343
Motion blur smearing now
weakens, at the tail, down to one step above the strength of the previous
frame's smear head (so there's a continuity of strength between frames).
#revision
1344
Font: added new characters: Œ œ
#revision
1345
CMISpinner and CMISlider now
support ints.
#revision
1347
Added two new motion blur
options: "Blur amount (eye)" and "Shutter angle (film)"
Duh, I had completely forgotten
that I have a CMotionBlur that looks after the motion blur (shader constants
etc)
#revision
1348
Grr, the cost of the motion blur
doesn't seem to be affected by the number of samples I'm telling it to use
(per pixel).That's annoying.
So it's currently faster to take the full number of samples regardless of
speed.I've now changed it back to
doing that.
Eye-style and film-style motion
blur both work correctly now.
9-juin-2008
3
#revision
1340
MotionBlur.fx,
Velocity.fx:
The number of samples per pixel for motion blur is now influenced by the
pixel's screen-space speed.
This is the way it was always supposed to work - where nothing's moving,
the motion blur only uses one sample.
The 'distanceForMaxSamples' option now works.
<-didn't work as an optimisation so I've changed it back (10th)
#revision
1342
Motion blur smearing is now
weighted so that it's weaker at the tail.It weakens down to one step above* the strength of the previous frame's smear head (so there's a
continuity of strength between frames).
C:\noctambule\debug\9_6_8_newMotionBlur.psd
It was faffy to get this working, because the compiler was being silly.I found that BlurPixelShader would only
work when I calculated 'totalStrength' using a formula rather than
incrementally.If I calculated it
incrementally, I could output it and see it had the right values; I just
couldn't divide 'frameRGB' by it without getting a complete malfunction.(????)
*(above) : todo<-done(10th)
8-juin-2008
8
Weapon #1:
Classic Star Wars type blaster or 'laser gun' - it shoots streaks of light
that cause sparks when they hit.
I'll have my streaks in blue, please.The gun itself could be a handgun with a brushed aluminium finish and
a few little LEDs...
This is the 'pop gun' that you start with or that you find easily at the
start of the game.But its effects
need to be totally impressive
and satisfying - first impressions and all.
#revision
1334
Added BlasterEffect.cpp & h:
Class that contains, updates and renders all blaster weapon effects
(CBlasterEffect)
There's one instance of this class, belonging to the CModeEnvironment
instance.
I expect "later on" the actual weapon objects that you pick up
and use will be called CWeapon, with subclasses like CBlaster /
CWeaponBlaster / CBlasterWeapon.
Added SEnvironmentRenderData::luminousWeaponEffects
This category includes blaster streaks,
explosions, electricity, etc.
#revision
1335
Master builds: Added NDEBUG to
the preprocessor line in the project settings.This turns 'assert' calls into ((void)0)
NB - This could easily cause hiccups for the
next master build - need to test it!!!
#revision
1336
Added Blaster.fx, the shader effect used for BlasterEffect.ESHADEREFFECT_BLASTER
BlasterEffect draws into
ERENDERTARGET_MOTIONBLUR, between the two passes of
ESHADEREFFECT_MOTIONBLUR.
The first of those passes forms a motion-blurred HDR image of the scene on
ERENDERTARGET_MOTIONBLUR.
The second of those passes applies the motion-blurred scene image into the
HDR backbuffer (frameRT).
Secondary motion blur is applied much later, in HDR end-scene, and it
includes the blaster streaks.
BlasterEffect is my first post-motion-blur-pre-HDR effect.
Eye-style motion blur (ie.
leaving traces of the previous frames as well as smearing each frame) is now
working - yay!Looks nice.It will look amazing when it's combined
with some shaky cam / wind buffetting.
Alt-tabbing to the game in
fullscreen mode now calls Reload if required.<-not
working yet - get this working and get it clearing the HDR backbuffer reliably!(CNoctambuleApp::VirtualRestoreDeviceObjects)
7-juin-2008
10,1667
Changed the strereo mode names
in English (including the enum names) to be more conventional:
"split left-right" -> "side-by-side"
ESTEREOSCOPYMODE_SIDE_BY_SIDE_(1/2)
"split top-bottom" -> "over-under"
ESTEREOSCOPYMODE_OVER_UNDER_(1/2)
#revision
1325
Added a new stereo mode:
"over-under gap" ESTEREOSCOPYMODE_OVER_UNDER_GAP
This is the same as over-under but with a black bar between the
views.
The size of the bar can be controlled from the stereoscopy menu
("over-under gap size").
The default gap size is 0.041015625 (42 / 1024.f).This is based on information about the
AnotherWorld Inc. "Another EYE 2000" glasses which need a gap of
that size when in under-over mode using its sync-doubler, at 60Hz at least
(info from Tril on mtbs3d.com).
#revision
1326
UtilWarning now displays a
warning icon instead of an error icon.
UtilWarning is used when the player's custom profiles are using out-of-date
option names.
#revision
1327
Added UtilDrawOverUnderGapQuad (similar to UtilDrawHalfScreenQuad but applies the over-under
gap size).
Tested that the default
"over-under gap" mode produces views 491 pixels tall separated by a
gap 42 pixels tall.
C:\noctambule\debug\7_6_8_overUnderGap.psd
#revision
1327
Compared a grab of
"over-under" with a grab of "over-under gap" using a gap
size of zero.
This showed that the bottom quad drawn by UtilDrawHalfScreenQuad
(over-under) was one pixel too tall at the top -> now fixed.
C:\noctambule\debug\7_6_8_overUnderGap.psd
This PSD also shows that the X positioning of the quads is correct.
#revision
1328
Added
g_game.flags.clearLDRBackbufferOnce.This is needed for the "over-under gap" mode, to clear the
gap to black.Could be needed again
for other stereo modes later, or for film borders etc.
It uses the current backbuffer count to clear as many times as it needs to,
on consecutive frames.
See also: g_game.clearLDRBackbufferOnce_count
TODO?: 'ground casts shadows'
option should apply to fallback shadows as well?
Ooh, just noticed these:
D3DBACKBUFFER_TYPE_LEFT
D3DBACKBUFFER_TYPE_RIGHT
I expect those are what you use for the VBE 3 hardware
page-flipping thing?
From the DX 9 doc for IDirect3DDevice9::GetBackBuffer:
"Stereo view is not supported in Direct3D
9, so the only valid value for this parameter is
D3DBACKBUFFER_TYPE_MONO."
#revision
1329
Tested that the multiply mode
was working properly in render target options, by setting frameRT:[/1,
*0.4794921875] to match up with the
"over-under gap" default gap size.At 1280x1024:
"EResolutionMode::frameMultiplication 1024
* 0.479492 produced result 491"
491 is the correct result.
Wrapped the printf above in a
RENDERTARGETOPTIONS_DEBUG define.
#revision
1330
The stereoscopy menu now
contains a duplicate of the 'interpupillary distance' spinner (from the
real-world menu).
All that was needed to keep the two spinners in sync was an on-change
callback that calls SetupVariableVerts on the other spinner.
#revision
1331
Realised that sprintf's default
precision for a float is SIX decimal places, not ALL decimal places.
This was causing precision to be lost when saving options.
I've now changed it so that floats, matrices and render targets save to the
text files using %.8f instead
of %f
#revision
1332
Setup:
The Custom.txt that gets included in builds is now a copy of
Custom_SHIPPED.txt.
This is blank apart from instruction comments.Currently, instruction comments are lost
each time Custom.txt is saved from the game - hence the need for this other
version of the file.
Setup: As of version 17.4, the
game install includes complete source code (C++ and HLSL).
The only files that are excluded are
- string table (in-game text) files - they will be included once they're
finalised;
- confidential material.Currently,
the 3DVisor interfacing code falls into this category, but that might change
because I think the eMagin SDK is now completely public (TODO: check).
NOTE: The code is not
shipped in a ready-to-run state (no project files, etc), although eventually
I would like to make it ready-to-run, so it can be used as an engine for new
VR-ready games (how cool would that be).Currently it's there for:
1. reference, to assist other programmers.No point re-inventing the wheel.
2. inspection by the target audience.I want them to see that my code is (hopefully) well-designed,
well-written and well-commented.I'll
also be putting the code online as nicely-formatted HTML very soon.
#revision
1332
Moved MatrixDeterminant out of the project (into stuff.cpp).
French code site, with French
comments etc, handy:
http://files.codes-sources.com
#revision
1332
Removed ESHADEREFFECT_ANAGLYPHFRAMECOPY from the project.
Forgot to make the '1' versions
of the split-screen stereo modes left-eye-first.Will probably do that next time.
I've not spent today very
productively - really just added the 'over-under gap' stereo mode and done
some housekeeping.
Tomorrow, I should start on weapons.Flashy lights and explosions...long
overdue.I can't wait to see how this
stuff turns out.
Started chipping away at the
code converter tool...but I've run out of steam for today.
5-juin-2008
3,5
TODO based on v17.2
feedback:
- option to make the game speed framerate-independent even at very low
framerates (disable the current 20fps floor).
- line sequential 2 (right eye first) seems to be the one that works for
Zalman monitors??
Realised that the checkerboard
mode isn't optimal with a half-by-half frameRT.So the masking wants to be done during the
main rendering, not at the end of the frame.
Files currently excluded from
source install:
3DVisor.cpp
3DVisor.h
Strings.h
StringsFrançais.hpp
StringsEnglish.hpp
Both/any setup projects now use
the following graphics:
website\new\favicon.ico (the game also gets it from here when it
builds).
C:\noctambule\setup\banner.jpg
Decided to ditch the source code
install and include all the source in the game install instead (with the
install folder strictly matching my working copy).
The source is only about a meg, and I want my target audience to be able to
inspect it as easily as possible.
Eventually, I might want to
make the whole installed project compilable, so you can download it and
compile it just like that.
DLP (checkerboard): Left image
goes first (top-left pixel is for the left eye).
Zalman (interlaced): Also left
eye first, I think.
#revision
1318
UtilDrawScreenQuad now takes a
parameter to specify that full-res half-pixel offsets (positive) should be
applied to the UVs.This defaults
false; TODO: the function should use the res of the current render target.
Tested line-sequential on master and slave at 1024*768 fullscreen.Left eye is first on both, as intended.
Added Chequer.fx, the same as
Interlace.fx but performs 'checkerboard' masking, eg. for 3D DLP
displays.
For anyone even more pedantic than me:
'Checkerboard' is the term used in the DLP whitepaper.It's an Americanism but it's simply the
term that's used - don't blame me ;)
#revision
1319
#revision 1320
CModeHUD::Render: Improved
stereo-related bail-out conditions for the crosshair.
I will get the crosshairs working properly in all stereo modes, one
day.They do draw in checkerboard
mode, but not line-sequential (because there'd be a big discrepancy between
the eyes).
They don't draw in any stereo mode when using a head-mounted display.
#revision
1321
CMenuTree::Render now takes into
account swapped stereo eyes (hasn't needed to until now).
The following stereoscopy modes
now have a '1' version and a '2' version.The '1' version is the more conventional configuration; the '2'
version swaps the eyes:
- split left-right
- split top-bottom
- checkerboard
- line sequential
- frame sequential
Version 17 bugs:
1. On Quadro, stereo interlacing isn't right.(screenshots:
C:\Noctambule\Builds\17_0\quadro).I
only had a very quick look at this at work.I'm pretty sure it was happening in fullscreen as well as windowed,
but the fullscreen grab (1280*1024) is fine (??)In the windowed grab (800*600) there's
about nine faulty horizontal lines.
Could Quadro be using strange pixel centres?I gather some graphics driver control apps
let you control this.That would break
all sorts of stuff.Could the monitor
be doing some strange scaling in fullscreen mode?<-fixed
in v17.2 (I had forgotten my half-pixel offsets again).
2. At work, I got the startup message that shoot.wav couldn't be found.But
the file was in the right place.
TODO, based on v17
feedback:
- start option to launch in English.
- language flags (in speech bubbles?) on the pause menu?
- fix the resolution spinners so they give you proper resolutions - several
people have mentioned this.
- ability to type values into spinners and combos.
- auto-sizing of the frame RT based on stereo mode
2-juin-2008
5,5
The new graphics folder layout
(see 29th May) can wait till version 18.
#revision
1307
The crosshair is now not drawn
in the various stereoscopic modes in which it doesn't yet appear the way it
should.This is temporary, just till I
fix it to draw properly in those modes.
#revision
1308
Split-off my placeholder car
into a new max file (graphics/objects/vehicles/AudiTT.max).The only thing it has in common with an
Audi TT is the dimensions.Still, it's
always seemed too small somehow (I'll investigate this).
The car is now XRef'd into leam.max.
Instances: Ran into another
auto-parenting problem case: the new instanced car outside Regent St. was
becoming a child of a drainpipe; the drainpipe is culled when its CullPlane
is backfacing....
Had some last-minute problems
with the instanced placeholder cars (strange normals), so instead I dug-out
the v15.1 level and used that for v17.0.
