I hope you have more luck with your exams than I do >.>
But I am really excited to see some progress 
Good luck again! 4.6 is released and has Static Lighting from Emissive Materials now. I am impatient how your integration will deal with the dyanmic lighting and emissive materials. Epic is going the right path with and your work is even going better and faster.
I want now 
Well people, I finished (most) of my exams! Got one more on the 20 of December, but I can start to dedicate some time to . After that, I will work 24/7 on . Got a question. Does anyone knows a method to update to the new engine release, without going manually and copying the changes file by file? I tried from here : How to Upgrade your Github Engine to the Newly Released Engine Version - C++ - Epic Developer Community Forums , but it didn’t work ( or I did it wrong…).
Any ideas?
Hey , you can update your project to the latest version of the engine by first launching the latest version of the engine from the UE4 main splash screen (the one with the link to the Marketplace and Library).
On the left side of the main splash page just select the latest version of the engine from the big yellow drop down then click it to launch - Once it’s launched you will see all of the projects, those which are on older builds will be greyed out. Just click on one of them then click OPEN and it will ask you if you want to convert the project in it’s place or make a duplicate for the update which i recommend.
will copy and convert all of the files to the new build.
Sorry, I wasn’t clear enough. I mean updating the source code, and keeping the changes I made
Ahh, ok, sorry, i have no experience with the Source Code yet so i couldn’t be of any help with that.
What branch are you working on? Usually I find that things work the best when I have some new branch that’s derived from . Then when I need to update my code for updates or because I’m about to put out a pull request it’s a simple matter of telling git to pull the latest changes from into my local branch, and merging those changes into my local branch. If the automatic merge succeeds (which it usually does) everything will be fine and dandy. Of course you have to have committed your changes onto the local branch first.
Or, in git commands:
[featurebranch +0 ~0 -0]$ git pull origin
[featurebranch +0 ~0 -0]$ git merge
It should just work if have the repository set up right and if Epic hasn’t pushed anything that conflicts with your code. If you have the repository set up wrong you might have to do some merging by hand to get things working. As you get more used to Git, you’ll have to do less of sort of thing.
If you have pushed on somewhere I’d definitely be interested in taking a look at it. My laptop definitely won’t be able to run , but my desktop probably can.
My levels are randomly generated on the fly so Lightmass isn’t an option. Some real time GI would be great. I wonder whatever happened to that SVOGI thing they used to have. Was it just too intense to run well?
I have been working on a branch I created inside my own private fork of the engine. Will still work? Can you explain a bit more? I’m a noob when it comes to
EDIT: I’m also checking out : How to create and apply a patch with Git · devroom.io . What would be the idea, create a patch for the 4.6 changes or for my own code?
EDIT 2: A strange thing I’m seeing is that the 4.6 branch doesn’t appears on my fork. Do I need to do something special to get it?
They changed the branch structure, there will be no 4.6 branch, its now in the release branch using a tag marking where the different released versions are in the history.
Im really not good at it, but maybe it hints you where to look or how to do it.
Oh and there is a free book about git.
I’d go with a merge. Rebasing is another possibility.
http://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
git checkout -b local-4.6-testmerge // create a new branch so you can destroy everything and start over if its beyond repair 
git merge release // try merging in all changes to the engine since you started working till top of the release branch, what is 4.6
Then you are going to solve all the merge conflicts that probably come up. Look in the book above it how thats done. When that is done, you execute Setup.bat to download the new dependencies and then you try to build your new engine. Id guess now you are getting build errors because the APIs changed, so resolve them too.
If that all succeeded and your engine behaves and runs, you can checkout the original branch you probably created to develop, merge in the branch created above and delete the temporary one. Or just continue to use branch for development.
The idea is following:
— you create separate branch in your fork based on release branch (let’s call it ahr-release-4.6)
— then you work as usual in that branch
— if Epic makes a release you check it out to ahr-release-4.6.1, create a patch out of your ahr-release-4.6 branch (which will contain only your own commits) and try to apply it to that branch to see if there’s any conflicts or problems you have to solve. If there’s none or you successfully found solutions for them you just close your ahr-release-4.6 and work on 4.6.1 (or you can even delete your old 4.6 and rename new one to it).
The patch will not take any epic commits, just the files you’ve edited. will make you be sure that your work is like overlapping current release branch. Simple merging new changes into your working branch is risky. Epic are not collaborating with you, they do their changes without any knowledge about yours.
Patch way is the best option, imho.
Resolving merge conflicts is the semiautomated way of resolving the errors that would occur when applying the patch manually. If one uses git merge or git rebase it will retain ones commit history.
Though I agree its risky in that it’s not fun at all and can be quite uneasy and might need more then one attempt…
Will be praying for your success.
Goodluck and godspeed mate !
Well, I think I got the idea of the patchs working, at least on a test repo. Now, when I go to my fork of the UE, I see I only have and 4.x branches, no release or promoted. Any idea on that? Do I need to do some kind of re-forking? Man, learning will take more time that integrating AHR, I’m sure of that…
No need for refork. You can create release branch by yourself and checkout Epic’s upstream/release to that branch.
Here’s how it’s done: http://stackoverflow.com/questions/4410091-import-upstream-branch-into-fork
Of course first you should make sure that you have upstream remote added:
[FONT=Courier New]D:\UE4\UnrealEngine [release]> git remote -v
origin https://.com/FamilioDevel/UnrealEngine.git (fetch)
origin https://.com/FamilioDevel/UnrealEngine.git (push)
upstream https://.com/EpicGames/UnrealEngine.git (fetch)
upstream https://.com/EpicGames/UnrealEngine.git (push)
If you don’t you should add it by command:
[FONT=Courier New]git remote add upstream https://.com/EpicGames/UnrealEngine.git
Thanks! I’ll try .
Anyway, I have the feeling my repo is gonna die tonight…
Well, I got to apply the patch, but getting 4 errors, where it says that the patch wont be aplied. Any idea how can I go and fix that?
Using the --reject option I got it to apply most of the patch, but still fails at the end.
It always fails on the same line, but if I see the file is empty on my file, and filled with some code on theirs. Is there a way I can do some kind of manual merge for each file that presents conflicts?
EDIT: Forget about that, it appears to be working now. Will have to download dependencies / build, but that’s gonna take all night long, so not much left to do here
I did it! Everything up and running. Will get to work on the shaders, both on the shader code itself, that’s mostly a copy and paste from my demo, but also on the classes and engine stuff, which is quite more difficult, but I think I have the right idea on how to proceed. Actually, only two parts remain to be implemented. One is the voxelization stage, that I’ll try to leave working week, and the other is the RSM, which I’ll have to find a way to hack myself into the engine code, as there are already routines to render RSM, used by the LPV, for example, so I hope to be able to use them as-is. Might have to modify something, but even if I do, and I break LPV, not really a problem there, as AHR will (hopefuly) replace both LPV and distance field AO.
Stay tuned people, good things are coming…
BTW, the full compile took 7 hours. Anyone feeling like donating an i7 5960x?